Windows Active Directory domains have been the way to leverage UNIX identity management in environments using Windows, given the tight integration with Kerberos, Windows accounts and ease of use. I cover a lot of this in TR-4073 (with a new LDAP-only TR coming out soon).
But, it doesn’t always fit all use cases.
For example, what if:
- You don’t have a Windows Active Directory domain?
- You don’t have access or permission to modify Active Directory domain accounts to use UNIX attributes?
- You don’t need a full-fledged AD domain with hundreds or thousands of users/groups, but only need a handful of users and groups for a single application?
There are likely other use cases that could apply here, but if you need LDAP without dealing with AD domains, we can leverage something called Windows Active Directory Lightweight Directory Services for identity management and LDAP services.
This also illustrates that pretty much *any* LDAP server can be used with ONTAP.
For example, this is a query from ONTAP to a server running AD LDS:
::*> getxxbyy getgrlist -node node1 -vserver NFS -username lds (vserver services name-service getxxbyyy getgrlist) pw_name: lds Groups: 1101 1102 ::*> getxxbyyy getpwbyname -node node1 -vserver NFS -username lds (vserver services name-service getxxbyyy getpwbyname) pw_name: lds pw_passwd: pw_uid: 1001 pw_gid: 1101 pw_gecos: pw_dir: pw_shell:
The configuration from ONTAP is identical for any LDAP server. In my case, I used the read-only LDAP client schema template named “MS-AD-BIS.”
Basic configuration steps:
- Create the LDAP client (“ldap client create” using the stock LDAP template MS-AD-BIS)
- Create/enable LDAP on the SVM (ldap create)
- Configure DNS on the SVM (dns create/modify)
- Modify ns-switch to use LDAP (ns-switch modify)
This was my LDAP client configuration:
::*> ldap client show -client-config LDS Vserver: NFS Client Configuration Name: LDS LDAP Server List: PARISI-WIN2019 (DEPRECATED)-LDAP Server List: - Active Directory Domain: - Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: false Schema Template: MS-AD-BIS LDAP Server Port: 389 Query Timeout (sec): 3 Minimum Bind Authentication Level: anonymous Bind DN (User): administrator Base DN: CN=LDS-LDAP,DC=PARISI-WIN2019 Base Search Scope: subtree User DN: - User Search Scope: subtree Group DN: - Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: false Use start-tls Over LDAP Connections: false Enable Netgroup-By-Host Lookup: false Netgroup-By-Host DN: - Netgroup-By-Host Scope: subtree Client Session Security: none LDAP Referral Chasing: false Group Membership Filter:
The hardest part of this configuration for me was the AD LDS side, as there are a bunch of manual steps involved.
Configuring AD LDS for LDAP Services
The best guide I came across was this one:
AD LDS Identity Mapping for Services for NFS
Even with this guide, however, there were a few tweaks that needed to be made to the steps. For example, in the guide, they used the AD Schema Manager. But since this isn’t a full AD instance, you might be stuck using ADSI Edit.
One place I also got stuck was a RTFM moment where I forgot in my initial configuration to create an application partition. This is essential, as this is where you will be creating the OUs/Containers, users and groups for the LDAP services.
When creating the new objects, you’ll want to consider populating the following fields in the users/groups for use with ONTAP (based on the MS-AD-BIS default schema).
Already populated at creation
When you create a new object, “cn” gets autopopulated. This is used to pull the Group names. (User names use “uid” by default)
- cn
Required
“Required” here means that ONTAP won’t be able to query for the object without these attributes populated properly.
- uid
- uidNumber
- gidNumber
Optional, but recommended
These attributes are recommended, but things will mostly work without setting them (unless you require proper group memberships).
- unixHomeDirectory
- memberUid or member (for group memberships)
Optional for specific use cases
This is basically only if you need things like netgroup services or name mapping to Windows users.
- sAMAccountName (for asymmetric name mappings to Windows)
- nisObject
- nisMapName
- nisMapEntry
- nisNetgroupTriple
- memberNisNetgroup
- loginShell (would need to be added manually)
User and Group creation
For user and group management/creation, you can either use ADSI Edit or PowerShell cmdlets. The ADSI Edit method is covered in the linked guide above.
For PowerShell you can use the standard Get-ADuser/Group and New-ADUser/Group. The catch is that you may have to specify the server – especially if your LDS server is a member of the AD domain.
For example:
PS C:\> get-aduser -Identity lds -server PARISI-WIN2019 -Properties uid,uidNumber,gidNumber,gecos,unixHomeDirectory DistinguishedName : CN=lds,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019 Enabled : False gecos : AD LDS User gidNumber : 1101 GivenName : Name : lds ObjectClass : user ObjectGUID : 087692ff-ae7f-4171-922a-98accfdfdaa8 SID : S-1-396492173-265181619-2703889971-1168526272-875569285-466579950 Surname : uid : {lds} uidNumber : 1001 unixHomeDirectory : /u/lds UserPrincipalName : lds@NTAP.LOCAL
PS C:\> Get-ADGroup -Identity ldsgroup1 -server PARISI-WIN2019 -Properties gidNumber,member,memberUid DistinguishedName : CN=ldsgroup1,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019 gidNumber : 1101 GroupCategory : Security GroupScope : Global member : {CN=lds,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019} Name : ldsgroup1 ObjectClass : group ObjectGUID : 5764424e-aba4-4e68-bff5-b7a6989d3d0c SID : S-1-396492173-265181619-2048905208-1111646721-233999250-1998119334 PS C:\> Get-ADGroup -Identity ldsgroup2 -server PARISI-WIN2019 -Properties gidNumber,member,memberUid DistinguishedName : CN=ldsgroup2,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019 gidNumber : 1102 GroupCategory : Security GroupScope : Global member : {CN=lds,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019} Name : ldsgroup2 ObjectClass : group ObjectGUID : 8aec090c-0865-4b80-bd4a-723884524ff6 SID : S-1-396492173-265181619-3623710820-1184275431-3423871139-2897951880
Note that in the group examples, I used “member” – this enables ONTAP to use RFC-2307bis. When you add members using “member,” you use the “Add DN” button in ADSI Edit or the Add-ADGroupMember PowerShell cmdlet. Then you use the full DN of the user.
For example:
PS C:\> Add-ADGroupMember -Identity ldsgroup2 -Members "CN=lds2,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019" -Server PARISI-WIN2019 PS C:\> Get-ADGroup -Identity ldsgroup2 -server PARISI-WIN2019 -Properties member DistinguishedName : CN=ldsgroup2,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019 GroupCategory : Security GroupScope : Global member : {CN=lds2,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019, CN=lds,CN=Accounts,CN=LDS-LDAP,DC=PARISI-WIN2019} Name : ldsgroup2 ObjectClass : group ObjectGUID : 8aec090c-0865-4b80-bd4a-723884524ff6 SID : S-1-396492173-265181619-3623710820-1184275431-3423871139-2897951880
Now ONTAP will be able to query for both groups for that user:
::*> getxxbyy getgrlist -node node1 -vserver NFS -username lds2 (vserver services name-service getxxbyyy getgrlist) pw_name: lds2 Groups: 1101 1102
So there it is – ONTAP using AD LDS for UNIX Identity Management.
Hi!
I have users using Linux but they use AD user to login as we use NIS in the backend for login process.
Do you think its possible to use user/group mapping with AD if the computers are not part of domain but the users are part of domain and unix attribute is set for them?
Thanks
LikeLike
Computers don’t need to be added to the domain for ONTAP to map users. The users just need to be able to be queried in the name services. If you set the UNIX attribute on the users being used for logins, then that would work fine if ONTAP is configured to look them up. TR-4835 covers it.
Click to access tr-4835.pdf
LikeLike