Setting up Single Sign-on SSH for hosts running multiple aliases (4251326)

1. Confirm that you can SSH to the current SSHd server using SSO. If using Putty make sure that the Service Prinicipal Name is blank.
Putty Configuration | Connection | SSH | Auth | GSSAPI parameters | "Service Principal Name".

2. Ensure that the DNS alias of the SShd host is resolvable from the client by PINGing by the aliasname

3. From the QAS SSHd server you would like to SSH to. Run the following command as root.
# /opt/quest/bin/vastool ktutil alias host/hostname.domainname host/aliasname.domainname

You can make sure this alias has been created by running the following command
# /opt/quest/bin/vastool ktutil list

4. Add the new SPNs (Service Prinicipal Names) to the computer object
You can either do this from a DC running Microsofts SetSPN as a domain administrator (This is available from Microsoft please see the link in additional information)
Or you can use vastool
# vastool -u Administrator setattrs -m host/ servicePrincipalName host/aliasname.domainname host/aliasname host/hostname host/hostname.domainname

Note: When using vatool setarrs you MUST specify the existing servicePrincipalNames values in the command line, otherwise they will be replaced. For example:

You can make sure this has been added by running
setspn -l hostname

EXAMPLE:
We have a host called vasclient.quest.local, and we have setup a DNS alias called ssh.quest.local we would do the following.

On the VAS client
# /opt/quest/bin/vastool ktutil alias host/vasclient.quest.local host/ssh.quest.local

On a DC
setspn -a host/ssh.quest.local vasclient

To test, use QuestSSH putty and connect to the FQDN name of this new alias (in our example ssh.quest.local).
You should see output similar to this

Using username "questuser".
Used GSSAPI service principal name "host/ssh.quest.local".
Last login: Wed Jan 23 13:02:19 2008 from 192.168.119.137
Hello.


Wrong principal in request
If you receive the error "wrong principal in request" in the sshd debug then this could be due to several reasons.

One item to check is the following attribute on the computer object or virtual host name:
# /opt/quest/bin/vastool -u host/ attrs <computername$ or host/> msDS-SupportedEncryptionTypes

If this attribute is set to 31, then the SSO could fail.
Therefore set this to 7 with the following command:
# /opt/quest/bin/vastool -u <ad admin> setattrs host/ msDS-SupportedEncryptionTypes 7

See the following Microsoft article on this option:
http://support.microsoft.com/kb/961302

Another cause of the 'Wrong principal in request' error is an incorrect local host entry on the SSH server.