In the sample output I see that you got a key for a debian-squeeze -- a hostname without any dots in it. This does kind of prove that you set up your reverse resolution to point to the short name. Is that really a non-FQDN name that you see, or was it edited for the question?
Kerberos should work with either, but you may to double check that the host itself thinks it is called debian-squeeze. Check that the forward -> reverse lookup inside debian-squeeze really resolves to debian-squeeze:
$ getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'
I haven't really heard of Kerberos being deployed with short names, so if you have a choice, it may be a good idea to stick with FQDNs.
Update:
The client is currently getting a key for the short name, but the server thinks it is properly named with a long name. Most likely the issue is there. Just to be sure, try the following:
Check the forward/reverse name lookup from the client. I.e.
$ getent hosts debian-squeeze | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'
The returned name is the one that the client will try to get a ticket for. Judging by your output, this is probably the short name.
Check what keys are present on the server.
$ sudo klist -k /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 host/debian-squeeze.realm@REALM
1 host/debian-squeeze.realm@REALM
1 host/debian-squeeze.realm@REALM
1 host/debian-squeeze.realm@REALM
...
In the list you should see a principal matching the hostname from the previous command. If it's not there, then that's your problem. If it is there...
Verify the key version on the kerberos server is the same as the one on debian-squeeze. On the client, get a key explicitly and verify the "KVNO" version at the end of the line:
$ kvno host/debian-squeeze.realm
host/debian-squeeze.realm@REALM: kvno = 1
At any rate, the hostname and "kvno" version in all these commands should match.
First, you should register straight and revert DNS record for new linux servers. Register this in windows domain.
Second, in Linux servers point DNS resolver to Windows, and modify /etc/hosts in linux for properly fields
Third, you must install Kerberos5 and winbind apps/modules/libraries
Fourth, configure /etc/krb5.conf with:
[libdefaults]
default_realm = YOUR.FULL.DOMAIN.WITH.UPPER.CHARS
[realms]
YOUR.FULL.DOMAIN.WITH.UPPER.CHARS = {
kdc = list of IPs windows domain servers
admin_server = one ip for master domain server
}
[domain_realm]
your.full.comain.with.lover.chars = YOUR.FULL.DOMAIN.WITH.UPPER.CHARS
[logging]
#example logging
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmin.log
default = FILE:/var/log/kerberos/krb5lib.log
Fifth, configure /etc/samba/smb.conf:
[global]
workgroup = YOUR.SHORT.DOMAIN.WITH.UPPER.CASE
netbios name = YOUR.SERVER.NAME.WITH.UPPER.CASE.WITHOUT.DOMAIN
realm = YOUR.FULL.DOMAIN.WITH.UPPER.CHARS
security = ads
password server = windows.ip.server.what.allows.password.change
wins server = as.above.supports.wins.messages
wins proxy = no
kerberos method = system keytab
dedicated keytab file = /etc/krb5.keytab
server string = write what you want using %h as host name
dns proxy = no
idmap config * : backend = rid
idmap config * : range = 10000-20000
winbind use default domain = Yes
winbind enum users = Yes
winbind enum groups = Yes
winbind nested groups = Yes
winbind separator = +
winbind refresh tickets = yes
template shell = /bin/bash
template homedir = /home/%D/%U
preferred master = no
inherit acls = Yes
map acl inherit = Yes
acl group control
Sixsth, verify you are able to connect using temporarly any user:
wbinfo -t #test only
net getdomainsid #should print local and domain identifier
wbinfo -u #domain user list, may take long time for many users
wbinfo -g #domain group list
Seventh, create technical user account that password never expires and cannot be changed. Others leave default. Collect that user in separate AD directory :)
Eighth, generate keytab:
net ads keytab create -U your.technical.user@YOUR.FULL.DOMAIN.WITH.UPPER.CHARS
then check /etc/krb5.keytab exists
At now you can configure other services, specially using ntlm helper. You can test for connection using:
ntlm_auth --username UPPER.CASE.SHORTNAME.DOMAIN+your.technical.username
write password and you should see status:
NT_STATUS_OK: Success (0x0)
At now you can configure PAM for authenticate many services, but I didn't do this. I succesfully use that config with apache2.2 ntlm authentication. I saw pam config for ssh and Xsession.
The main idea is, only winbind authenticates to Active Directory. All other services authenticates locally to winbind by any way. Winbind is part of samba. If you don't need samba, install only winbind, this installs some samba libraries.
Sometimes when you configure connection, wbinfo fails to connect. You must then wait for a moment, 5 or more minutes for domain info propagation.
Of course, time on all mashines should be in sync. Configure NTP for this.
I'm using debian, but ubuntu makes all similar to debian :) good luck.
Best Answer
If you are using ssh public key to authenticate, you are only authenticating to your ssh daemon, not to the system. SSH daemon would claim that it performed authentication and then log you in into the shell. While this process might be utilizing PAM stack to set up your login session, it, however, does not handle authentication through the PAM stack.
I may state obvious to you, but Kerberos ticket can only be obtained if you use software that requests it. On a typical system such a ticket would be requested through PAM
authstage if eitherpam_sssorpam_krb5is defined inauthstack of the PAM configuration used by your application. When such application (e.g.sshd) is skippingauthstage, none of PAM modules responsible for authentication are called and no Kerberos ticket can be obtained this way.When Kerberos client attempts to request an initial ticket granting ticket (TGT), it and Kerberos KDC exchange a list of so-called "pre-authentication methods". In practice, these are the methods used to authenticate your client against KDC. One method chosen by a client, if accepted by the KDC, implements actual authentication process. There are no Kerberos pre-authentication methods that use a SSH key-pair for authentication, so you cannot use SSH key-pair to obtain a TGT. All standard password-based pre-authentication methods are built around both Kerberos client and Kerberos KDC knowning the long-term key (password) of the user principal, even though they do not pass it over the network. There is currently one method that does not rely on a password and it is so-called PKINIT method which relies on completing authentication using public key certificate infrastructure.
What can you do? You might want to turn it all around and use a smartcard for authentication instead. Smartcard authentication is supported by Kerberos as a 'pkinit' pre-authentication method. In addition to that, SSH daemon is capable to treat a certificate from your smartcard for authentication similar to the SSH key-pair case.
If you'd use PKINIT authentication, you have two ways: either obtain a Kerberos TGT with PKINIT on your workstation and login to SSH daemon on other machine using Kerberos ticket you have locally, or use your smartcard certficiate to login to SSH daemon as a SSH key and then use smartcard forwarding to request a Kerberos ticket on the host directly. In the former case your original TGT would not be forwarded to the SSH host automatically, unless you have asked for a ticket delegation. In the latter case you'd still need to request a TGT.
Regardless which method to use, you can definitely benefit from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_certificates_in_idm/index
If you don't want or cannot use smartcards, then the only method left is to use Kerberos login directly and forget about SSH key-pair authentication.