Using this link, I have set up a server that is properly joined to an Active Directory server, but for some reason I can not authenticate to that server with a kerberos ticket on several test-users that I made on my laptop.
All users on my local laptop have the same .ssh/config and all use the same /etc/krb5.conf; all users are also able to succesfully get a valid ticket from the AD, just by using kinit. However, the problems arise when I try to ssh to the aforementioned server that is joined to AD.
When I try to login with my own account, 'parkel', it asks me for my password, I type in my AD-password and I get authenticated to login to the server, the first time I logged in, my homedir was made properly and I was assigned to the groups that were set in gidNumber in the AD; all seemed okay in the world. I tested changing gidNumber in AD, all changes were active right away after relogging. All still seemed okay in the world.
That's when the issues started; after seeing my success, I made two test-accounts in AD, copies of my own AD-account that was working before, 'test1' & 'test2'. I changed to that account on my laptop, did kinit and got a ticket. However, when I tried to login to the server, it's only trying to authenticate with password and no mention is ever made in the logs that it's trying to authenticate using pam_sss, since the local user does not exist, this will fail miserably.
I have checked out way more google searches and documentation than I care to admit, but I'm really at a loss here; I'm pretty sure I'm overlooking some stupid small detail, but I really can't find where I'm going wrong.
Included is some output from sshd log on the server and my krb5.conf on the server and on my client.
SSHD output
Dec 10 11:59:04 ldaptest.vs.lan sshd[2384]: Authorized to parkel, krb5 principal parkel@VS.LAN (ssh_gssapi_krb5_cmdok)
Dec 10 11:59:04 ldaptest.vs.lan sshd[2384]: Accepted gssapi-with-mic for parkel from 192.168.100.2 port 56752 ssh2
Dec 10 11:59:04 ldaptest.vs.lan systemd[1]: Created slice user-2001.slice.
Dec 10 11:59:04 ldaptest.vs.lan systemd[1]: Starting Session 3 of user parkel.
Dec 10 11:59:04 ldaptest.vs.lan systemd[1]: Started Session 3 of user parkel.
Dec 10 11:59:04 ldaptest.vs.lan systemd-logind[776]: New session 3 of user parkel.
Dec 10 11:59:04 ldaptest.vs.lan sshd[2384]: pam_unix(sshd:session): session opened for user parkel by (uid=0)
Dec 10 11:59:10 ldaptest.vs.lan sshd[2410]: Invalid user test1 from 192.168.100.2
Dec 10 11:59:10 ldaptest.vs.lan sshd[2410]: input_userauth_request: invalid user test1 [preauth]
KRB5.conf SERVER
[libdefaults]
default_realm = VS.LAN
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = yes
[realms]
VS.LAN = {
kdc = ad01-test.vs.lan:88
admin_server = ad01-test.vs.lan:749
default_domain = vs.lan
}
[appdefaults]
pam = {
debug = true
ticket_lifetime = 36h
renew_lifetime = 36h
forwardable = true
krb4_convert = false
}
[logging]
default = FILE:/var/log/krb5/kdc.log
kdc = FILE:/var/log/krb5/kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
KRB5.conf CLIENT
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = false
rdns = false
default_realm = VS.LAN
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
VS.LAN = {
kdc = 172.19.254.5
}
[domain_realm]
.vs.local = VS.LAN
vs.local = VS.LAN
SSSD.conf SERVER
[sssd]
domains = vs.lan
services = nss, pam, pac
config_file_version = 2
[nss]
[pam]
[pac]
[domain/vs.lan]
## Comment out if you want offline logins
# cache_credentials = true
ldap_id_mapping = False
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ldap_schema = ad
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
ad_server = ad01-test.vs.lan
Best Answer
As a future reference, this log line is the key:
It tells you that ssh can even find the user, so the next step in debugging should be to enable sssd logs and see why
getent passwd test1
is not working.Glad sssd works for you now!