Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment
On Thu, Jul 30, 2015 at 05:35:53PM -0500, Dan Mossor wrote: > Greetings, folks. > > So, I've been fighting with getting a trust set up between FreeIPA 4.1 on > CentOS 7.1 and Windows Server 2008r2 for nearly a week. Today I finally came > to a conclusion as to what my issue is. > > I operate a secure network in which we have configuration guidlines for > securing Windows that we have to meet in order to recieve what's known as an > "Authority to Operate", or ATO. A lot of this configuration is done in the > Global Policies. > > Today I stumbled across one error buried in the Windows Security event log, > and when correllated with the errors I was seeing from FreeIPA led me to our > policy. The error that popped up in the event log was "The user has not been > granted the requested logon type at this machine." The logon type was "3", > which is network, and the Logon Process and Authorization Package were both > Kerberos. > > Cross referenced with the error on the IPA server: > "WARNING: Search on AD DC WINSRV.ad.domain.net:3268 failed with: > Insufficient access: 8009030C: LdapErr: DSID-0C0904DC, comment: > AcceptSecurityContext error, data 569, v1db1 Invalid Credentials" > > Digging into our Domain Controller policy, I found that "Access this > computer from the network" is restricted to Domain Users, Domain > Controllers, Domain Computers, Domain Admins, and BUILTIN\Administrators. I > attempted to add a context that would allow the IPA server to log on, and > got so far through the wizard that it let me select the trusted domain to > search and returned a list of security contexts, but when I attempted to add > one (Authenticated Users), I recieved the error that it couldn't be found > because the server was inaccessable. I saw no errors on the IPA side during > this transaction. 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 > > -- > Dan Mossor, RHCSA > Systems Engineer > Fedora Server WG | Fedora KDE WG | Fedora QA Team > Fedora Infrastructure Apprentice > FAS: dmossor IRC: danofsatx > San Antonio, Texas, USA > > -- > 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 -- 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
Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment
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? Dan -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- 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
Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment
On Fri, Jul 31, 2015 at 09:23:53AM -0500, 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? yes and no :-) The keytab is used to get a TGT and then a cross-realm TGT from the IPA KDC. The IPA KDC will add a PAC to the TGTs which contains additional authorization data including SIDs. The PAC is then used on the Windows side to evaluate if access is granted or not. bye, Sumit > > Dan > > -- > Dan Mossor, RHCSA > Systems Engineer > Fedora Server WG | Fedora KDE WG | Fedora QA Team > Fedora Infrastructure Apprentice > FAS: dmossor IRC: danofsatx > San Antonio, Texas, USA -- 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
Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment
On 07/31/2015 10:08 AM, Sumit Bose wrote: On Fri, Jul 31, 2015 at 09:23:53AM -0500, 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? yes and no :-) The keytab is used to get a TGT and then a cross-realm TGT from the IPA KDC. The IPA KDC will add a PAC to the TGTs which contains additional authorization data including SIDs. The PAC is then used on the Windows side to evaluate if access is granted or not. bye, Sumit Building on what you said regarding the one-way trust, I already have an IPA user in Active Directory that I created when I was initially setting this up as a synchronized domain instead of a trust. There are two ways I can go here - I can either revert back to the password sync and replication, or somehow convince IPA to use that user for the trust relationship. I suspect it will impossible without a patch to use a user account instead of Kerberos for the trust, so that leaves going back to the replication setup. Our ultimate goal in the environment is single sign on - when our users log into their Windows 7 workstations, they shouldn't then have to log into the chat server, the wiki, and mercurial; all those extra services running on Linux should be able to accept the Active Directory credentials. One final option I have, since this is a very small network, is to just join my Linux servers to the Active Directory domain, and not use the FreeIPA intermediary. -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- 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
Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment
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 (-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
Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment
On Fri, 31 Jul 2015, Dan Mossor wrote: On 07/31/2015 10:08 AM, Sumit Bose wrote: On Fri, Jul 31, 2015 at 09:23:53AM -0500, 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? yes and no :-) The keytab is used to get a TGT and then a cross-realm TGT from the IPA KDC. The IPA KDC will add a PAC to the TGTs which contains additional authorization data including SIDs. The PAC is then used on the Windows side to evaluate if access is granted or not. bye, Sumit Building on what you said regarding the one-way trust, I already have an IPA user in Active Directory that I created when I was initially setting this up as a synchronized domain instead of a trust. There are two ways I can go here - I can either revert back to the password sync and replication, or somehow convince IPA to use that user for the trust relationship. I suspect it will impossible without a patch to use a user account instead of Kerberos for the trust, so that leaves going back to the replication setup. The latter is impossible. You can try FreeIPA 4.2 with one-way trust once it becomes available to your platform. I've asked on this list two weeks ago if anyone is interested in seeing FreeIPA 4.2 released for CentOS in a test repo before it comes via official path after release of the next Red Hat Enterprise Linux update. To day I received zero responses which leaves me puzzled. -- / 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
