cert authentication and 'aliasing' nss providers
paul.moore at centrify.com
Wed Apr 27 06:25:48 AEST 2016
This is a feature request. I can code it up but I am curious to know if it would be accepted, if its been discussed before etc.
Many NSS providers (ldap, AD, ...) do what I call 'aliasing'. The directory behind the NSS providers knows the user by an enterprisey name and knows how to map that name to a logical passwd entry. For example
$ getent passwd joe.doe at pmdev.test
that's because the NSS provider knows that on this system joe.doe at pmdev.test<mailto:joe.doe at pmdev.test> is joe.doe. On another system he might be joed, on others he might not exist at all.
In many SSO scenarios the client doesn't know the unix name of the user and so sends the enterprisey name (it knows that one) during user auth. For example GSSAPI enabled putty running on Windows knows who the logged in AD user is and connects using that name, on the server side the NSS lookup resolves the user to the correct local name. All good
Regarding openssh certificate support - this doesnt work. The principal list in the cert is checked against the pw->name NSS field, i.e. the unix name of the user. But the enterprisey software that issued the cert doesn't know what name that will be so it doesn't know what to put in the principal list in the cert.
My current solution is to put the full name in the principal list and use AuthorizedPrincipalsCommand in sshd_config
AuthorizedPrincipalsCommand /usr/bin/adquery user -P %u
That tool returns the full name when given the unix name of a user.
However this solution works but doesn't scale well for a general purpose solution
- That tool may not exist for some NSS providers
- The mods to the sshd_config are different depending on what NSS provider is in use
The simple solution is to change the sshd code to check the principal list against the username sent in the auth request (this is the full user name) instead of checking the pw->name field.
More information about the openssh-unix-dev