Integrating Unix into Active Directory while maintaining UNIX style security - 2018 Update
Integrating Unix into Active Directory while maintaining UNIX style security - 2018 update
In 2010 I had the unique challenge to research how to integrate Unix and Linux into Active Directory. While new tools such as Centrify, Quest, and Likewise (now BeyondTrust) had clients you could install on your Unix clients they came a heavy cost; and in most cases, was a NIS layer (at the time) over your AD to enable UID/GID mappings.
I wanted to have the ability to use OpenSource tools and enable the ability to have auto assigned UID to user and groups so UNIX style security could be used on resources such as NFS. The solution I came up with borrowed from Apples Magic Triangle configuration using Apple Open Directory and Active Directory. The exception was I leveraged OpenLDAP as the UID/GID database while keeping User and Group objects in Active Directory. This enabled Linux to use the opensource SAMBA client to authenticate to Active Directory while using OpenLDAP for the corresponding UID/GID for the user and groups objects using SAMBA algorithm that generates the UID/GID using the Active Directory Object SID.
This solution works well for the time, but there are two other solutions that we can leverage that is far easier to configure and provide a more native experience.
Option 1 SSSD
The System Security Services Daemon (SSSD) supports Active Directory integration. Like previous SAMBA clients a UID/GID is auto-generated from the Object SID, but it's only system wide. This works great if you are using a server and you want to secure only to this server, but if you are leveraging shared services across multiple servers, we need a solution to have a central UID/GID database that is unique within the Directory.
My first thought was to do what I did before and leverage Python Active Directory module on a dedicated Linux server and have it generate objects UID using SSSD query; but that limited me to the SID and increased complexity account creation. Also, for existing accounts I would have to have a script that queried all objects then update the object to retrofit my environment.
My biggest concern outside of increasing complexity was ensuring a unique UID/GID in a multi domain Active Directory Forest. Using the SID might not be unique; especially when dealing with other trusted domains.
In Active Directory the Object GUID is unique to its forest and unique forest wide. I wanted to create an algorithm using the GUID to create a unique UID/GID. While researching ways to convert the 128-bit integer to 32-bit UID I came across a blog where an engineer reversed engineered Apple's client algorithm that does just that: https://themacwrangler.wordpress.com/2016/11/29/reversing-the-ad-plugin-uid-algorithm/
Using the script examples above I created a PowerShell script when objects are created a UID is updated in the LDAP field for that object. By doing this not only will our clients that are configured to use SSSD for Active Directory authentication - with SSSD using Active Directory to obtain the UID/GID - native clients that are using LDAP and/or Kerberos (like an Isilon NFS server); and Windows clients with NFS enabled, can use the UID of the object to grant access allowing Unix style security on Unix based services.
After the object is created the following needs to be performed to generate the UID of the Object and then an update to the object can be performed and the proper LDAP attribute can be updated (UID for user and GID for Groups)
# Change GUID to UID
$ConvertGUIDToUID = New-Object guid(,($object) | %{[Convert]::ToInt64(($_.guid.split('-')[0]),16) -band '2147483647'}
# update user uidNumber
Set-ADObject -Identity $ObjectDN -Add @{uidNumber=$ConvertGUIDToUID} -Server $dc -Credential $Cred
# update group gidNumber
Set-ADObject -Identity $ObjectDN -Add @{gidNumber=$ConvertGUIDToUID} -Server $dc -Credential $Cred
Option 2 OpenLDAP Pass-through Authentication
Like my previous blog this option leverages OpenLDAP, but instead of using OpenLDAP to be an IDMAP database to store UID/GID you leverage OpenLDAP as your main authentication and leveraging SSL trust between OpenLDAP and Active Directory the authentication is forwarded to AD from LDAP.
The benefit to this is you don't have to rely on SSSD Samba based client to authenticate and use native LDAP client with UNIX. Since we are using native LDAP, this allows for broader client support; especially older Unix systems that might have issues talking to Active Directory as an LDAP provider.
In my opinion the use case I prefer to use this in is for clients that might reside in the DMZ; for example, an LDAP based service that doesn't support SAML or OpenID, and provides SSO for clients. Only SSL needs to be allowed between OpenLDAP and Active Directory.
For UID and GID we still need to generate a unique ID for the object. We can mirror the object in LDAP (can cause issue) and have a domain specific ID mapping like traditional LDAP or we can auto-generate as we did in Option 2 and allow the pass-through authentication to retrieve the UID and GID.
In my opinion Option 1 is preferred unless you have a specific use case that requires this option.
https://blogs.msdn.microsoft.com/alextch/2012/04/25/configuring-openldap-pass-through-authentication-to-active-directory/
