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@IPA.DOMAIN
 2. I obtain a ticket granting ticket, krbtgt/IPA.DOMAIN@IPA.DOMAIN
 3. Using TGT I ask my KDC for a ticket for ldap/dc.ad.domain@AD.DOMAIN
 3.1. Since this service is not from my realm, my KDC looks for existence
      of principal krbtgt/IPA.DOMAIN@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@AD.DOMAIN and a
      referral to AD DC to complete acquisition of the ticket to
      ldap/dc.ad.domain@AD.DOMAIN
 4. Using ticket to krbtgt/IPA.DOMAIN@AD.DOMAIN, I ask AD DC to give me
    a ticket to ldap/dc.ad.domain@AD.DOMAIN.
 4.1. AD DC looks into content of the ticket to krbtgt/IPA.DOMAIN@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@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@IPA.DOMAIN
 - cifs/master.ipa.domain@IPA.DOMAIN
 - HTTP/master.ipa.domain@IPA.DOMAIN
for all IPA masters which were initialized with ipa-adtrust-install --
and nothing else. Any IPA client's host/client.ipa.domain@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@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@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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to