Thoughts about AD integration with IPA
Have you ever spent days wondering what would happen if the Windows guys talked to the Linux guys and visa versa? It’s odd; organizations decide to manage identity with Active Directory and thus the Linux server estates come in as an afterthought, an add-on that needs to be integrated – and maintained – alongside the Windows boxes.
Centralised authentication is one of those integration points that someone like me has to address. A preexisting Active Directory is usually (and regrettably) the cornerstone for this concept, as it provides authentication to the desktop estate where end users usually remain, for better or for worse. Introducing Linux central authentication to servers and to users is something wonderful. Something to be celebrated by a party! No longer would you manage individual users and passwords, no longer would you have to go through individual servers deleting previous sysadmins that have pained and upset you by leaving you in this mess and no longer would you have the arduous task of clearing up after them. You can remove them from your centrally managed Linux authentication once and for all.
In fact, you can do one better than that. If your company is managing users via AD, and you are integrating AD with IPA you have the possibility to offload this task to the Windows team. They can go and disable the user from AD. All you have to do is sit back and relax.
The Integration Choice
I know my thoughts wandered at this point. All the different possibilities. How best to integrate, what are the benefits of the different options, why would people care. Decision time!
Assuming that you already decided on using IPA and have one up and running and ready to go, you will want to consider the following two possibilities:
- the user sync from AD to IPA
- the cross realm trust
User synchronizing from AD with IPA may leave you with user name collision, if you have similarly named users. It also doesn’t allow SSO and unique identities but it does give you the option of having two different passwords in the windows and Linux realms. Some may consider that a plus. On the down side, user management on putting users into groups is also necessary because all the users are synchronized but not the AD groups.
I prefer the cross realm trust route. It means that user management falls completely under the S.E.P field. All I need to care about is which groups of users does the company trust enough not to harm themselves and others when using Linux. Each realm would be responsible in authenticating its own users and the groups the groups that the users are in would allow them to be authorized for certain actions.
NOTE: If you don’t have an IPA server ready to go, you have very limited time, you’re not allowed to run 2 different realms, you don’t care about policy enforcement, consider integrating directly with AD. SSSD and kerberos should help you manage different users from AD and your Linux boxes talk directly to the AD forest.
The rocky road
I already have an installation that I can use for my integration. The previous article showed how to disable most IPA features. This part is showing how to live with your choices with IPA 4.1 and AD 2012R2.
IPA should have a netbios name as well as samba and winbind services configured:
ipa-adtrust-install --netbios-name=MGMT
Enable the following ports:
firewall-cmd --permanent --add-port={138/tcp,139/tcp,445/tcp,138/udp,139/udp,389/udp,445/udp}
firewall-cmd --reload
Add the service records to DNS. This is one of the things that allows AD to talk to IPA on a native level:
_ldap._tcp.dc._msdcs IN SRV 0 100 389 idm _kerberos._tcp.dc._msdcs IN SRV 0 100 88 idm _kerberos._udp.dc._msdcs IN SRV 0 100 88 idm _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 389 idm _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 idm _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 idm
And create the trust (Yes, in IPA 4.1 you do have to stop the firewall and then add the trust, there are ports that aren’t mentioned in the docs):
systemctl stop firewalld ipa trust-add --type=ad "windows.local" --admin Administrator --password systemctl start firewalld ipactl status reboot
Check that the trust exists by finding the domains
[root@idm ~]# ipa trust-find windows.local --------------- 1 trust matched --------------- Realm name: windows.local Domain NetBIOS name: WINDOWS Domain Security Identifier: S-1-5-21-4218785893-350090421-2374357632 Trust type: Active Directory domain ---------------------------- Number of entries returned 1 ----------------------------
OK, now one kerberos realm trusts the other and this is how it should look:
The group mapping
To enable your AD users to log on to clients of IPA, you need to tell IPA how to find them. To do that you will need to add the AD group where your user is as an external group in IPA. Let’s assume you want to allow the AD Domain Admins group to ssh on to servers.
ipa group-add --desc='AD Domain admins' domain_admins_external --external ipa group-add-member domain_admins_external --external 'WINDOWS\Domain Admins
These groups won’t have any POSIX attributes as they are external groups. Every user that connects to a Linux computer requires a Linux UID and GID. This means that you will need to create another group to contain the mapped external one:
ipa group-add --desc='AD Posix Domain Admins' domain_admins ipa group-add-member domain_admins --groups domain_admins_external
Great! You can now start configuring your sudo, host based access control and Identity Views!
She ITs and Giggles 