[Freeipa-devel] [PATCH] 0202 support UPNs for trusted domain users

Martin Babinsky mbabinsk at redhat.com
Thu Jun 9 17:08:25 UTC 2016


On 06/09/2016 06:46 PM, Alexander Bokovoy wrote:
> On Thu, 09 Jun 2016, Martin Babinsky wrote:
>> On 06/07/2016 07:35 PM, Alexander Bokovoy wrote:
>>> On Tue, 07 Jun 2016, Martin Babinsky wrote:
>>>> On 06/07/2016 06:38 PM, Alexander Bokovoy wrote:
>>>>> On Tue, 07 Jun 2016, Martin Babinsky wrote:
>>>>>> On 06/06/2016 12:34 PM, Alexander Bokovoy wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Add support for additional user name principal suffixes from
>>>>>>> trusted Active Directory forests. UPN suffixes are property
>>>>>>> of the forest and as such are associated with the forest root
>>>>>>> domain.
>>>>>>>
>>>>>>> FreeIPA stores UPN suffixes as ipaNTAdditionalSuffixes multi-valued
>>>>>>> attribute of ipaNTTrustedDomain object class.
>>>>>>>
>>>>>>> In order to look up UPN suffixes, netr_DsRGetForestTrustInformation
>>>>>>> LSA RPC call is used instead of netr_DsrEnumerateDomainTrusts.
>>>>>>>
>>>>>>> For more details on UPN and naming in Active Directory see
>>>>>>> https://technet.microsoft.com/en-us/library/cc739093%28v=ws.10%29.aspx
>>>>>>>
>>>>>>>
>>>>>>> https://fedorahosted.org/freeipa/ticket/5354
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Hi Alexander,
>>>>>>
>>>>>> a few comments:
>>>>>>
>>>>>> 1.)
>>>>>>
>>>>>> there are some PEP8 violations in the patch. Not all of them need to
>>>>>> be fixed, though (line overhangs < 5 characters are OK by me).
>>>>>>
>>>>>> """
>>>>>> ./ipaserver/dcerpc.py:1199:80: E501 line too long (80 > 79
>>>>>> characters)
>>>>>> ./ipaserver/dcerpc.py:1200:80: E501 line too long (83 > 79
>>>>>> characters)
>>>>>> ./ipaserver/dcerpc.py:1258:40: E203 whitespace before ':'
>>>>>> ./ipaserver/dcerpc.py:1263:80: E501 line too long (81 > 79
>>>>>> characters)
>>>>>> ./ipaserver/dcerpc.py:1271:80: E501 line too long (90 > 79
>>>>>> characters)
>>>>>> ./ipaserver/dcerpc.py:1272:80: E501 line too long (82 > 79
>>>>>> characters)
>>>>>> ./ipaserver/plugins/trust.py:490:9: E128 continuation line
>>>>>> under-indented for visual indent
>>>>>> ./ipaserver/plugins/trust.py:490:80: E501 line too long (93 > 79
>>>>>> characters)
>>>>>> ./ipaserver/plugins/trust.py:490:92: E202 whitespace before ']'
>>>>>> ./ipaserver/plugins/trust.py:493:80: E501 line too long (83 > 79
>>>>>> characters)
>>>>>> ./ipaserver/plugins/trust.py:1461:80: E501 line too long (80 > 79
>>>>>> characters)
>>>>>> ./ipaserver/plugins/trust.py:1462:59: E202 whitespace before ']'
>>>>>> ./ipaserver/plugins/trust.py:1544:1: E302 expected 2 blank lines,
>>>>>> found 1
>>>>>> ./ipaserver/plugins/trust.py:1638:1: E302 expected 2 blank lines,
>>>>>> found 1
>>>>>> """
>>>>> I've fixed trust.py part, the dcerpc.py fixes in 0201 should be enough
>>>>> now -- breaking following line is not giving any reasonable benefit:
>>>>>
>>>>>          res['ipantflatname'] =
>>>>> unicode(t.forest_trust_data.netbios_domain_name.string)
>>>>>
>>>>
>>>> Looking at the code, it would be IMHO more readable to directly append
>>>> dict literals to the result like so:
>>>>
>>>> """
>>>> --- a/ipaserver/dcerpc.py
>>>> +++ b/ipaserver/dcerpc.py
>>>> @@ -1269,18 +1269,20 @@ def fetch_domains(api, mydomain, trustdomain,
>>>> creds=None, server=None):
>>>>            tname = unicode(t.forest_trust_data.dns_domain_name.string)
>>>>            if tname == trustdomain:
>>>>                continue
>>>> -            res = dict()
>>>> -            res['cn'] = tname
>>>> -            res['ipantflatname'] =
>>>> unicode(t.forest_trust_data.netbios_domain_name.string)
>>>> -            res['ipanttrusteddomainsid'] =
>>>> unicode(t.forest_trust_data.domain_sid)
>>>> -            result['domains'][tname] = res
>>>> +
>>>> +            result['domains'][tname] = {
>>>> +                'cn': tname,
>>>> +                'ipantflatname': unicode(
>>>> +                    t.forest_trust_data.netbios_domain_name.string),
>>>> +                'ipanttrusteddomainsid': unicode(
>>>> +                    t.forest_trust_data.domain_sid)
>>>> +            }
>>>>        elif t.type == lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME:
>>>>            tname = unicode(t.forest_trust_data.string)
>>>>            if tname == trustdomain:
>>>>                continue
>>>> -            res = dict()
>>>> -            res['cn'] = tname
>>>> -            result['suffixes'][tname] = res
>>>> +
>>>> +            result['suffixes'][tname] = {'cn': tname}
>>>>    return result
>>>> """
>>> Makes sense. Fixed.
>>>
>>>>
>>>> Also there is a whitespace before colon here:
>>>> """
>>>> +    result = {'domains': {}, 'suffixes' : {}}
>>>>                                       ^
>>>> """
>>>> Please fix that and I will be a happy engineer.
>>> Fixed.
>>>
>>>>
>>>>>> 2.)
>>>>>>
>>>>>> Should the ipaNTAdditionalSuffixes attribute be case insensitive? It
>>>>>> makes sense but I'm just asking so that we don't end changing the
>>>>>> schema later.
>>>>> ipaNTAdditionalSuffixes is defined as
>>>>>
>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.11.75 NAME
>>>>> 'ipaNTAdditionalSuffixes' DESC 'Suffix for the user principal name
>>>>> associated with the domain' EQUALITY caseIgnoreMatch SYNTAX
>>>>> 1.3.6.1.4.1.1466.115.121.1.15)
>>>>>
>>>>> There should be no problem with case sensitivity already.
>>>>>
>>>> OK I presume that the UPN suffixes on AD are also case-insensitive so
>>>> everything should be alright.
>>> Yes, as everything realm-related on AD side, they are case-insensitive.
>>>
>>> Updated patch attached.
>>
>> 1.) there is one unused import that makes pylint choke:
>>
>> """
>> ************* Module com.redhat.idm
>> install/oddjob/com.redhat.idm.trust-fetch-domains:6:
>> [W0611(unused-import), ] Unused errors imported from ipalib)
>> Makefile:137: recipe for target 'lint' failed
>> make: *** [lint] Error 1
>> """
> Fixed, thanks. I wasn't attentive to why it considered that error.

We are continuously tighting pylint checks in order to help us improve 
(or at least not worsen) the code quality.

>
>> 2.) The UPN suffixes are added during trust establishment and I can
>> also kinit as the enterprise principal using one of UPNs, but only
>> when using two-way trust. Is this expected? I was not able to find any
>> clue in the design page but maybe I was just not looking hard enough.
> No, it works just fine for one-way trust as well. The way UPNs used in
> AD is a bit awkward -- you define them globally for the whole forest
> first and then assign specific UPN suffix for the user account in the
> account properties. Only then you can use the suffix for this user:
>
> [root at f24-master ~]# net ads search -S w12.ad.test -k cn=grumpy |grep
> userPrincipalName
> userPrincipalName: grumpy at torchwood
>
> [root at f24-master ~]# KRB5_TRACE=/dev/stderr kinit -E -C grumpy at torchwood
> [9135] 1465490159.655327: Resolving unique ccache of type KEYRING
> [9135] 1465490159.655408: Getting initial credentials for
> grumpy\@torchwood at IPA.AD.TEST
> [9135] 1465490159.656798: Sending request (176 bytes) to IPA.AD.TEST
> [9135] 1465490159.656994: Initiating TCP connection to stream
> 192.168.5.117:88
> [9135] 1465490159.657122: Sending TCP request to stream 192.168.5.117:88
> [9135] 1465490159.657655: Received answer (169 bytes) from stream
> 192.168.5.117:88
> [9135] 1465490159.657679: Terminating TCP connection to stream
> 192.168.5.117:88
> [9135] 1465490159.657715: Response was from master KDC
> [9135] 1465490159.657741: Received error from KDC: -1765328316/Realm not
> local to KDC
> [9135] 1465490159.657756: Following referral to realm AD.TEST
> [9135] 1465490159.657783: Sending request (168 bytes) to AD.TEST
> [9135] 1465490159.674764: Resolving hostname w12.ad.test.
> [9135] 1465490159.679514: Sending initial UDP request to dgram
> 192.168.5.111:88
> [9135] 1465490159.680158: Received answer (171 bytes) from dgram
> 192.168.5.111:88
> [9135] 1465490159.688085: Response was not from master KDC
> [9135] 1465490159.688141: Received error from KDC:
> -1765328359/Additional pre-authentication required
> [9135] 1465490159.688203: Processing preauth types: 16, 15, 19, 2
> [9135] 1465490159.688252: Selected etype info: etype aes256-cts, salt
> "AD.TESTgrumpy", params ""
> [9135] 1465490159.688285: PKINIT client has no configured identity;
> giving up
> [9135] 1465490159.688315: PKINIT client has no configured identity;
> giving up
> [9135] 1465490159.688342: Preauth module pkinit (16) (real) returned:
> 22/Invalid argument
> [9135] 1465490159.688368: PKINIT client has no configured identity;
> giving up
> [9135] 1465490159.688394: Preauth module pkinit (14) (real) returned:
> 22/Invalid argument
> Password for grumpy\@torchwood at AD.TEST: [9135] 1465490162.317092: AS key
> obtained for encrypted timestamp: aes256-cts/C61F
> [9135] 1465490162.317176: Encrypted timestamp (for 1465490162.505923):
> plain 301AA011180F32303136303630393136333630325AA105020307B843,
> encrypted
> ADD327ACC03C99C821D9FBBE280866D6342D3CE1BBA2C720CF5A5BEBA586ECD0034CD2C3448F5FD6D66219DB77DC51D81C8C1D6D01A87AC9
>
> [9135] 1465490162.317228: Preauth module encrypted_timestamp (2) (real)
> returned: 0/Success
> [9135] 1465490162.317272: Produced preauth for next request: 2
> [9135] 1465490162.317328: Sending request (246 bytes) to AD.TEST
> [9135] 1465490162.346793: Resolving hostname w12.ad.test.
> [9135] 1465490162.352714: Sending initial UDP request to dgram
> 192.168.5.111:88
> [9135] 1465490162.353537: Received answer (1442 bytes) from dgram
> 192.168.5.111:88
> [9135] 1465490162.366042: Response was not from master KDC
> [9135] 1465490162.366094: Processing preauth types: 19
> [9135] 1465490162.366139: Selected etype info: etype aes256-cts, salt
> "AD.TESTgrumpy", params ""
> [9135] 1465490162.366190: Produced preauth for next request: (empty)
> [9135] 1465490162.366235: AS key determined by preauth: aes256-cts/C61F
> [9135] 1465490162.366328: Decrypted AS reply; session key is:
> aes256-cts/BD45
> [9135] 1465490162.366382: FAST negotiation: unavailable
> [9135] 1465490162.366416: Initializing
> KEYRING:persistent:0:krb_ccache_dSjqZkD with default princ grumpy at AD.TEST
> [9135] 1465490162.366488: Storing grumpy at AD.TEST ->
> krbtgt/AD.TEST at AD.TEST in KEYRING:persistent:0:krb_ccache_dSjqZkD
> [9135] 1465490162.366550: Storing config in
> KEYRING:persistent:0:krb_ccache_dSjqZkD for krbtgt/AD.TEST at AD.TEST:
> pa_type: 2
> [9135] 1465490162.366585: Storing grumpy at AD.TEST ->
> krb5_ccache_conf_data/pa_type/krbtgt\/AD.TEST\@AD.TEST at X-CACHECONF: in
> KEYRING:persistent:0:krb_ccache_dSjqZkD
>
> As you can see, the realm was considered non-local and a referral to the
> correct realm was issued, then kinit followed the referral and finally
> we've got the ticket for grumpy at AD.TEST because canonicalization was
> asked. If no canonicalization would be asked, the principal would be
> enterprise one but, again, from the other realm:
>
> [root at f24-master ~]# klist
> Ticket cache: KEYRING:persistent:0:krb_ccache_lIqrVtl
> Default principal: grumpy\@torchwood at AD.TEST
>
> Valid starting       Expires              Service principal
> 06/09/2016 19:45:16  06/10/2016 05:45:16  krbtgt/AD.TEST at AD.TEST
>     renew until 06/10/2016 19:45:13
>
>
>
Hmmm,

when I establish a one-way trust I can kinit with the user having UPN 
suffix:

  kinit -E jdoe at crew207
Password for jdoe\@crew207 at DOM-207.ADREALM.COM:
[root at vm-183 ~]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_gHJAT3H
Default principal: jdoe\@crew207 at DOM-207.ADREALM.COM

Valid starting       Expires              Service principal
06/09/2016 17:56:31  06/10/2016 03:56:31 
krbtgt/DOM-207.ADREALM.COM at DOM-207.ADREALM.COM
         renew until 06/10/2016 17:56:26


However when I issue 'ipa trust-show' I do not see any UPN suffixes 
associated with the trust because 'ipaNTAdditionalSuffixes' attribute is 
not populated on the trusted domain object while in the tow-way trust 
case it is and 'trust-*' commands show the UPNs as expected.

ipa trust-show  dom-207.adrealm.com
   Domain NetBIOS name: DOM-207
   Domain Security Identifier: S-1-5-21-2334637434-2721788842-3715042423
   Trust direction: Trusting forest
   Trust type: Non-transitive external trust to a domain in another 
Active Directory forest
   Realm name: dom-207.adrealm.com

(it doesn't matter if I create external one-way trust or not, the UPNs 
are not pulled from AD DC in either case)

-- 
Martin^3 Babinsky




More information about the Freeipa-devel mailing list