Identity management of light and dark sides
Tomasz Torcz
Directory Services are great when you have more than 3 users and/or machines to care about. Most basic part is the same password on every system and
UIDs/GIDs in order. More advanced stuff means expiring those pesky users, replicating their login data and implementing SSO. Red Hat has given us the (Free)IPA suite, which is very nicely integrated LDAP+Kerberos+DNS+WebUI. It feels like a solid product and works really well in Unix environment.
Nb. implementing Solaris/Linux Kerberos-secured NFSv4 environment feels really great. And IPA tremendously helps with that.
But Unix is not only enviroment sysadms have to struggle with. Sometimes the dark times come, and the need arises to synchronise user accounts from MS Active Directory into IPA. It's generally good idea to have consolidated user data, but Windows ecosystem is totaly alien to me. There is one gotcha that really surprised me recently.
IPA, by design, only talks with AD using TLS. There's a way to switch nsDS5ReplicaTransportInfo from TLS to plain
LDAP, but it's only possible when the replica agreement has been already established. It's not an option during initial setup. Is this a problem? As
it turns out, the other kid in the yard plays by completely opposite rules.
Active Directory, by default, does not use TLS. More over, there is no GUI switch labelled "Use TLS" or similar. To enable SSL, one have to install SSL/TLS certificate into Windows store. After a reboot, AD's LDAP server speaks TLS. Again, there is no checkbox or indication of using TLS in the interface. In this moment sslscan comes handy as a verification tool.
Anyway, part of IPA is the Dogtag certificate system. It makes producing certs a breeze. Just copy *.req created on Windows to IPA server
and do:
-
ipa cert-request request.req --add(the principal is "HOST/your.ad.server.hostname") ipa cert-show serial- copy-paste Base64 encoded part to separate file and voila - that's your windows cert.
Other things to remember: when documentation says "kdestroy" - do it. If you skip this part, you won't get password prompt for Directory
Manager. You will be authenticated using current Kerberos ticket and probably all you will get is a cryptic message about being unable to
"add" on "cn=config".
Oh, and FreeIPA documentation is quite comprehensive, but could use some updating. Documentation talks about Windows 2003, some directories do not exist in more-recent-than-decade-old versions.
*** **Archived comments:** **Stephen Gallagher** _2013-09-03 18:53:35_http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
These days, you almost certainly do not want to be using the sync setup to talk to Active Directory. The link above is a HOWTO on setting up FreeIPA in a cross-realm trust agreement with Active Directory (similar to adding FreeIPA as another domain in an Active Directory forest).
Stephen,
trusts look good, but are have other disadvantages. Usernames look "funny" with domain parts attached, user records cannot be augmented with shell, uid and other unix properties, and AD user's cannot be granted access to IPA WebUI.
I'm still looking howto properly allow "AD trusted" users to manage OVirt.
Hi Tomasz,
In the recent or upcoming versions of FreeIPA, the development team has addressed many of your comments.
Usernames look funny? Check out the default_domain_suffix option.
User records cannot be augmented with shell? See the shell_fallback option.
Looking for POSIX information with trusted users? IPA 3.3 supports that.
I'm not entirely sure about AD users logging in to IPA's WebUI, but in general, AD users have Kerberized access to IPA's resources.
There is a lot of development going on in the FreeIPA land :-)
Comments
Comments powered by Disqus