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.
