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
([email protected]) 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/[email protected]
2. I obtain a ticket granting ticket, krbtgt/[email protected]
3. Using TGT I ask my KDC for a ticket for ldap/[email protected]
3.1. Since this service is not from my realm, my KDC looks for existence
of principal krbtgt/[email protected] 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/[email protected] and a
referral to AD DC to complete acquisition of the ticket to
ldap/[email protected]
4. Using ticket to krbtgt/[email protected], I ask AD DC to give me
a ticket to ldap/[email protected].
4.1. AD DC looks into content of the ticket to krbtgt/[email protected]
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/[email protected])
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/[email protected]
- cifs/[email protected]
- HTTP/[email protected]
for all IPA masters which were initialized with ipa-adtrust-install --
and nothing else. Any IPA client's host/[email protected]
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/[email protected] ticket is checked
against the list of SIDs in your policy.
4.3. As you don't have IPA SIDs in the policy,
host/[email protected]
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 ([email protected]) 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
