[Freeipa-users] Setting up Active Directory trusts in a secure environment

[Alexander Bokovoy]

On Fri, 31 Jul 2015, Dan Mossor wrote:
>On 07/31/2015 02:52 AM, Sumit Bose wrote:
>>
>>Thank you for the detailed analysis. I guess the 'server was
>>inaccessible' error is due to the fact that currently FreeIPA does not
>>have a global catalog, because Windows typically tries to get SIDs from
>>remote objects from the Global Catalog.
>>
>>>
>>>So, to those of y'all that operate in secure environments, what trick do you
>>>use to fully integrate IPA and Active Directory?
>>
>>With FreeIPA-4.2 the one-way trust feature is introduced. The main
>>difference to the current scheme is that with one-way trust the FreeIPA
>>server does not use its host credentials (host keytab) from the IPA
>>domain to access the AD DC but uses the trusted domain user
>>(IPADOM$@AD.DOMAIN) to access the AD DC. Since this is an object from
>>the AD domain it should be possible to assign the needed permissions to
>>this object.
>>
>>Currently I have no idea how this can be solved with older version.
>>Maybe there is a toll on the Windows side which lets you add SIDs
>>manually into the "Access this computer from the network" policy? If
>>there is one you can try to add IPA-SID-515 (where you have to replace
>>IPA-SID by the IPA domain SID).
>>
>>HTH
>>
>>bye,
>>Sumit
>>
>
>I didn't think the SID was even being evaluated - the authentication 
>being attempted was through Kerberos, which I uderstand only uses host 
>keytabs, not SIDs. Am I correct in this situation?
No, you are not.

For starters, authentication with Kerberos deals with tickets, not
keytabs. You obtain a ticket granting ticket, either with the explicit
password or with credentials from the keytab. Using a ticket granting
ticket you ask KDC to give a ticket towards your target service. In case
of cross-forest bi-directional trust, this results roughly in a
following sequence:

  1. I have credentials for host/master.ipa.domain at IPA.DOMAIN
  2. I obtain a ticket granting ticket, krbtgt/IPA.DOMAIN at IPA.DOMAIN
  3. Using TGT I ask my KDC for a ticket for ldap/dc.ad.domain at AD.DOMAIN
  3.1. Since this service is not from my realm, my KDC looks for existence
       of principal krbtgt/IPA.DOMAIN at AD.DOMAIN in own database
  3.2. If bi-directional trust is established, my KDC has this principal
       in its own database and it can issue me a ticket for this service
  3.4. I'm getting a ticket to krbtgt/IPA.DOMAIN at AD.DOMAIN and a
       referral to AD DC to complete acquisition of the ticket to
       ldap/dc.ad.domain at AD.DOMAIN
  4. Using ticket to krbtgt/IPA.DOMAIN at AD.DOMAIN, I ask AD DC to give me
     a ticket to ldap/dc.ad.domain at AD.DOMAIN.
  4.1. AD DC looks into content of the ticket to krbtgt/IPA.DOMAIN at AD.DOMAIN
       and searches there for a special record, named MS-PAC
       (https://msdn.microsoft.com/en-us/library/cc237917.aspx). MS-PAC
       contains a privilege attribute certificate issued by my KDC,
       explaining who is the original user in terms of the AD domain:
       what is his name, SID, group membership and so on. A ticket
       without MS-PAC will be refused immediately because AD DC cannot
       otherwise map kerberos principal (host/master.ipa.domain at IPA.DOMAIN)
       to something it needs to run own policy decision.

And this is where everything is tied together. A KDC on IPA master is
instructed to only issue MS-PAC records to tickets of user principals if
they have SID assigned to them, _and_ to following principals:
  - host/master.ipa.domain at IPA.DOMAIN
  - cifs/master.ipa.domain at IPA.DOMAIN
  - HTTP/master.ipa.domain at IPA.DOMAIN
for all IPA masters which were initialized with ipa-adtrust-install --
and nothing else. Any IPA client's host/client.ipa.domain at IPA.DOMAIN
couldn't get MS-PAC record and couldn't talk to AD DC, for example.

These special principals (host/, cifs/, HTTP/) get assigned a SID of a
Domain Computers group in IPA domain (<IPA SID>-515).

Back to AD DC.

  4.2. AD DC runs a policy check on who can access LDAP service. In a
       default setup it would be 'Authenticated users' which allows
       anyone with a Kerberos ticket containing a valid MS-PAC record to
       be granted access to LDAP service. As you have changed the
       policy, this does not apply anymore, and the list of SIDs AD DC
       will find in host/master.ipa.domain at IPA.DOMAIN ticket is checked
       against the list of SIDs in your policy.

  4.3. As you don't have IPA SIDs in the policy, host/master.ipa.domain at IPA.DOMAIN
       is rejected access to LDAP service.

The real problem here is in the fact that you couldn't add IPA domain
SIDs to the policy. To do so, Windows UI needs to be able to resolve
names of groups from IPA forest to SIDs and it is unable to do so
because IPA does not provide such a service.

With one-way trust IPA masters are changed to use a special object that
exists in AD forest root domain. You can then assign access rights to
this object (IPA$@AD.DOMAIN) using your Windows UI.


-- 
/ Alexander Bokovoy