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