One of the least used features in NetWorker is the option for external authentication of user accounts for use with NMC. This is normally discussed in the context of integrating NMC authentication into an Active Directory environment, but in theory, other LDAP v3 compliant directory services are compatible.
So over the weekend, I gave myself two goals: learn enough on the Ukulele to be able to play a song my boyfriend would recognise and integrate a lab NetWorker environment with the directory services provided by my OS X Server (10.9).
Surprisingly, I managed both – though perhaps unsurprisingly, the NMC/LDAP authentication was the trickier goal to get sorted out.
The first step I followed was to create a new group in LDAP called ‘nsradmin’, and placed into that group the user accounts that I wanted to be able to administer the NetWorker server. With that done, I switched back to NMC:
From within NMC’s main window, go to Setup > Configure Login Authentication… and choose to configure an external repository, as shown below:
My external repository is pretty basic; as a home server, it’s a fairly flat structure, so the configured repository resembled the following:
In the distinguished name, I referenced the full DN to the directory administrator. This is normally undesirable; a preferred option would be to configure another directory user that has appropriate read permissions but limited to no modification permissions. I didn’t feel like diving into that level of control within LDAP and it was only a lab server so I plunged ahead with the actual directory administrator.
The user and group search path are both straight forward:
- User Search Path: cn=users,dc=miranda,dc=turbamentis,dc=int
- Group Search Path: cn=groups,dc=miranda,dc=turbamentis,dc=int
For Apple’s directory services, you need to modify most of the options in the Advanced field, viz:
- User ID Attribute becomes ‘uid’ for non-AD servers
- User Object Class is ‘apple-user’
- Group Object Class is ‘apple-group’
- Group Member Attribute is ‘memberUid’
For what it’s worth, I confirmed those settings by using the ldapsearch tool on the directory server:
# ldapsearch -LLL -h miranda.turbamentis.int -b "cn=users,dc=miranda,dc=turbamentis,dc=int" -D "uid=diradmin,cn=users,dc=miranda,dc=turbamentis,dc=int" -W
...snip...
dn: uid=services,cn=users,dc=miranda,dc=turbamentis,dc=int uid: services uidNumber: ... homeDirectory: /Users/services cn: Services User sn: User loginShell: /bin/bash givenName: Services objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: posixAccount objectClass: shadowAccount objectClass: top objectClass: extensibleObject objectClass: apple-user
# ldapsearch -LLL -h miranda.turbamentis.int -b "cn=Groups,dc=miranda,dc=turbamentis,dc=int" -D "uid=diradmin,cn=users,dc=miranda,dc=turbamentis,dc=int" -W
...snip...
dn: cn=nsradmin,cn=groups,dc=miranda,dc=turbamentis,dc=int objectClass: top objectClass: posixGroup objectClass: extensibleObject objectClass: apple-group apple-group-realname: nsradmin cn: nsradmin apple-ownerguid: ... apple-generateduid: ... gidNumber: ... apple-group-memberguid: ... apple-group-memberguid: ... memberUid: pmdg memberUid: services
If you’re encountering issues with the configuration (and more importantly, subsequent testing), I’d recommend setting the LDAP Debug Level to 1 so that you can see what sort of LDAP searches NMC is performing – these can be seen from the gstd.raw file in the NetWorker Management Console logs directory. If you’re not sure whether you’ve got all the details correct, by the way, just hit the Next> button … you can’t progress to the next screen unless NMC can successfully query the list of groups and names based on the details you’ve entered.
Clicking next, you’ll be prompted to confirm which users and roles will have ‘Console Security Administrator Role’ – this is a critical field; this defines the users who can re-invoke this form after the switchover to external authentication has happened:
Make sure there’s at least one actual user account defined in there. This is where I came-a-cropper the first few times – I assumed I could just use the group in there and it would be sufficient. (I’d need to go back and check against an Active Directory associated NMC server to confirm whether it’s any different there as I can’t recall off-hand.)
Click Next> again once you’ve populated that – again, NMC will query and confirm the validity of the entered details before it lets you progress:
You’ll then be prompted to confirm which servers you want to distribute the authority file to – in my case, since GST services are running on the same host as the backup server itself, it’s two instances of the same server, NetWorker and NMC. The distribution should log as follows:
Click Finish, but whatever you do, don’t yet exit NMC. There’s a few more bits and pieces you need to do. Specifically, you have to do the following:
- Add at least the referenced security console administrator user (from above) as a user in NMC, assigning the user all security roles.
- Equally, add that user (e.g., user=pmdg,host=hostName) to the NetWorker Application Administration list (within the NetWorker Administration console).
- Test the login of that user using another browser or RDP session. Once you exit the console session you’ve been using, internally defined accounts will be disabled. (In fact, they actually already are, but because this session remains authenticated while you remain connected.)
In my testing, I found that (at least with OSX 10.9 Server LDAP), I couldn’t successfully define administrative NetWorker control via the External Roles field in the User Groups list, viz.:
That is, it wasn’t sufficient to define ‘group=nsradmin’ or an external role of ‘nsradmin’ to grant NetWorker administrative rights to anyone in that external group. (I suspect as much as anything that this is a peculiarity between the operation of OS X 10.9 Server directory services and NMC than a failing in NMC itself.)
Even with the slightly less integrated approach, where administrative accounts will need to be named individually within the User group for NetWorker, there are still definite advantages of external authentication integration:
- Reducing number of passwords you have to remember in your overall environment
- Auditor satisfaction that an account disabled in directory services will be disabled from NMC access
- Auditor satisfaction of named user account tracking (rather than local-to-NMC and possibly generic accounts) in NMC
In case you’re wondering – if someone with a directory account tries to log in and there hasn’t been an account defined in NMC, NMC will automatically create the account, but not assign any privileges to it. This allows a previously authenticated administrator to quickly edit the privileges.
One final note – if you do happen to mess up the authentication process and can’t log in, the short-term solution is quite straight forward:
- Stop the NetWorker Management Console services
- On the NMC server, touch under the Management Console ‘cst’ directory a file called ‘authoverride’.
- Restart the NMC services
- Log in as administrator
- Either switch back to local authentication, or adjust the external roles/etc as appropriate
- Stop NMC services
- Remove the ‘authoverride’ file
- Restart the NMC services
- Verify it’s working
Keeping all that in mind, it’s relatively straight-forward to jump into the realm of external user authentication with NMC – and that procedure above is your get-out-of-gaol card if for some reason, your directory services goes down.