On Mon, Sep 01, 2014 at 01:53:36PM +0200, Pavel Březina wrote:
On 08/26/2014 10:50 AM, Sumit Bose wrote:
>On Thu, Jul 24, 2014 at 03:42:38PM +0200, Pavel Březina wrote:
>>On 07/22/2014 09:47 PM, Sumit Bose wrote:
>>>On Tue, Jul 22, 2014 at 05:55:21PM +0200, Pavel Březina wrote:
>>>>On 07/22/2014 01:27 PM, Sumit Bose wrote:
>>>>>Hi,
>>>>>
>>>>>this series of patches should solve
>>>>>https://fedorahosted.org/sssd/ticket/1749 . The solution is a bit
>>>>>different than the one outline in
>>>>>https://fedorahosted.org/sssd/wiki/DesignDocs/NSSWithKerberosPrincipal
>>>>>but after a couple of iterations I prefer this solution because it
adds
>>>>>only a minimal amount of new code and automatically covers features
like
>>>>>mid-point refresh, because the same code path is used. If we agree
on
>>>>>this approach I'll update the design page accordingly.
>>>>>
>>>>>The outline is in the commit message of the 5th patch, I'll copy
it here
>>>>>for easier reference:
>>>>>
>>>>>With this patch the NSS and PAM responders can handle user principal
>>>>>names besides the fully qualified user names.
>>>>>
>>>>>User principal names are build from a user name and a domain suffix
>>>>>separated by an '@' sign. But the domain suffix does not
necessarily has
>>>>>to be the same as the configured domain name in sssd.conf of the
>>>>>dynamically discovered DNS domain name of a domain. The typical use
case
>>>>>is an Active Directory forest with lots of different domains. To not
>>>>>force the users to remember the name of the individual domain they
>>>>>belong to the AD administrator can set a common domain suffix for
all
>>>>>users from all domains in the forest. This is typically the domain
name
>>>>>used for emails to make it even more easy to the users to remember
it.
>>>>>
>>>>>Since SSSD splits name and domain part at the '@' sign and
the common
>>>>>domain suffix might not be resolvable by DNS or the given user is not
a
>>>>>member of that domain (e.g. in the case where the forest root is used
as
>>>>>common domain suffix) SSSD might fail to look up the user.
>>>>>
>>>>>With this patch the NSS and PAM responder will do an extra lookup for
a
>>>>>UPN if the domain part of the given name is not known or the user
was
>>>>>not found and the login name contained the '@' sign.
>>>>>
>>>>>The first patch contains the needs changes for the LDAP provider,
>>>>>patches 2, 3 and 4 some related cleanup and improvements. The main
>>>>>functionality is in the 5th patch.
>>>>>
>>>>>bye,
>>>>>Sumit
>>>>
>>>>Hi,
>>>>I went through the code and IMHO the approach you've chosen is good.
>>>
>>>thank you for the fast response.
>>>
>>>>
>>>>Can you make "U" value a macro?
>>>
>>>sure, new version attached. (Patch 1 and 5 changed)
>>>
>>>bye,
>>>Sumit
>>
>>Hi,
>>you left unused variable "res" in pam_check_user_search() introduced
in
>>patch 3 and its usage was removed in patch 5. I'm sending a simple patch
>>that fix this, feel free to squash it into patch 5.
>
>thank you for the review and the patch, done.
>
>>
>>The code looks good and id and su commands with upn works, however it seems
>>that group membership is not calculated correctly (only primary group is
>>shown).
>>
>>[client: ~]$ id test-user(a)ad.pb
>>uid=1751601108(test-user) gid=1751600513(domain users)
>>groups=1751600513(domain users),1751601106(sudo users)
>>[client: ~]$ id test-user(a)upnad.pb
>>uid=1751601108(test-user) gid=1751600513(domain users)
>>groups=1751600513(domain users)
>>
>>If I run id after su, the membership is correct:
>>[client: ~]$ su test-user(a)upnad.pb
>>Password:
>>[client: /home/pbrezina]$ id
>>uid=1751601108(test-user) gid=1751600513(domain users)
>>groups=1751600513(domain users),1751601106(sudo users)
>>context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>>
>
>Thank you for catching this. My testing focus was that the UPN can be
>used at the login prompt. But since the UPN might be used in group list
>related calls as well I added support in the initgroups code path as
>well.
>
>New version of the patches is attached.
>
>bye,
>Sumit
Ack.
Pushed to master:
899d1bdc048cd74518170d7d9535d76d3f46d4af
7d2437adc312d3322d36043ff458fafdb4b7f2cf
17c4d901ecf62fa9d641d46c9e92032b0deaaa36
cda952ca3e00d324c7e53eeaeda394eb0d142818
25a387c2e90c74b27a26ea207503df8e4b6a1a76
84d50b69d286f041aa96a948b008d311d8755075
Since IFP contains pretty much a private copy of the check_cache
function, I guess we would get the UPN lookups for free when we
use the same code for NSS and IFP cache lookups (which is something
Pavel would be working on now..)