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
