Edit: Würde es helfen, wenn ich das ganze in deutsch schreibe? Ich habe das Gefühl, dass für eine stärkere internationale Ausrichtung englisch bevorzugt würde. Wenn dann allerdings Forumsmitglieder entmutigt werden zu antworten, wäre das doppelt doof für mich.
In order to keep it simple I broke down my current problem (Kerberos authenticated NFS 4) in several smaller problems.
Setup
- UCS Active Directory Domain Controller
- Backupserver (not AD Backup or Domain Backup!)
I joined the backupserver to the domain. getent passwd shows results from the AD. I assume the backupserver is successfully integrated into the domain.
On the DC, I added the SPN using samba-tool spn add nfs/backupserver1.example.com backupserver1$ and checked the success:
root@ucs-addc:~$ samba-tool spn list backupserver1$
INFO: Current debug levels:
all: 8
tdb: 8
printdrivers: 8
lanman: 8
smb: 8
rpc_parse: 8
rpc_srv: 8
rpc_cli: 8
passdb: 8
sam: 8
auth: 8
winbind: 8
vfs: 8
idmap: 8
quota: 8
acls: 8
locking: 8
msdfs: 8
dmapi: 8
registry: 8
scavenger: 8
dns: 8
ldb: 8
tevent: 8
auth_audit: 8
auth_json_audit: 8
kerberos: 8
drs_repl: 8
smb2: 8
smb2_credits: 8
dsdb_audit: 8
dsdb_json_audit: 8
dsdb_password_audit: 8
dsdb_password_json_audit: 8
dsdb_transaction_audit: 8
dsdb_transaction_json_audit: 8
dsdb_group_audit: 8
dsdb_group_json_audit: 8
Processing section "[netlogon]"
Processing section "[sysvol]"
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Processing section "[global]"
pm_process() returned Yes
schema_fsmo_init: we are master[no] updates allowed[no]
backupserver1$
schema_fsmo_init: we are master[no] updates allowed[no]
User CN=backupserver1,CN=Computers,DC=example,DC=com has the following servicePrincipalName:
nfs/backupserver1.example.com
I exported the keytab with
samba-tool domain exportkeytab /tmp/backupserver1.keytab --principal=nfs/backupserver1.example.com
samba-tool domain exportkeytab /tmp/backupserver1.keytab --principal=backupserver1$
copied it on the target machine using scp, imported it using ktutil copy backupserver1.keytab /etc/krb5.keytab and checked the success using ktutil list
Current situation
When trying kinit -t /etc/krb5.keytab nfs/backupserver1.example.com, I get
kinit: krb5_get_init_creds: Client (nfs/backupserver1.example.com@EXAMPLE.COM) unknown
On the kdc –which also is the AD DC–, the log shows
Okt 21 10:44:46 ucs-addc samba[5773]: conn[kdc_tcp] c[ipv4:10.3.30.100:47105] s[ipv4:10.3.20.22:88] server_id[5773.3][5773]: [2020/10/21 10:44:46.470996, 3, pid=5773] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Okt 21 10:44:46 ucs-addc samba[5773]: conn[kdc_tcp] c[ipv4:10.3.30.100:47105] s[ipv4:10.3.20.22:88] server_id[5773.3][5773]: Kerberos: AS-REQ nfs/backupserver1.example.com@EXAMPLE.COM from ipv4:10.3.20.3:60672 for krbtgt/EXAMPLE.COM@EXAMPLE.COM
Okt 21 10:44:46 ucs-addc samba[5773]: conn[kdc_tcp] c[ipv4:10.3.30.100:47105] s[ipv4:10.3.20.22:88] server_id[5773.3][5773]: [2020/10/21 10:44:46.473125, 3, pid=5773] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Okt 21 10:44:46 ucs-addc samba[5773]: conn[kdc_tcp] c[ipv4:10.3.30.100:47105] s[ipv4:10.3.20.22:88] server_id[5773.3][5773]: Kerberos: UNKNOWN -- nfs/backupserver1.example.com@EXAMPLE.COM: no such entry found in hdb
Okt 21 10:44:46 ucs-addc samba[5773]: conn[kdc_tcp] c[ipv4:10.3.30.100:47105] s[ipv4:10.3.20.22:88] server_id[5773.3][5773]: [2020/10/21 10:44:46.473218, 2, pid=5773] ../../auth/auth_log.c:647(log_authentication_event_human_readable)
Okt 21 10:44:46 ucs-addc samba[5773]: conn[kdc_tcp] c[ipv4:10.3.30.100:47105] s[ipv4:10.3.20.22:88] server_id[5773.3][5773]: Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[nfs/backupserver1.example.com@EXAMPLE.COM] at [Wed, 21 Oct 2020 10:44:46.473207 CEST] with [(null)] status [NT_STATUS_NO_SUCH_USER] workstation [(null)] remote host [ipv4:10.3.20.3:60672] mapped to [(null)]\[(null)]. local host [NULL]
Okt 21 10:44:46 ucs-addc samba[5773]: conn[kdc_tcp] c[ipv4:10.3.30.100:47105] s[ipv4:10.3.20.22:88] server_id[5773.3][5773]: {"timestamp": "2020-10-21T10:44:46.473289+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 1}, "eventId": 4625, "logonType": 3, "status": "NT_STATUS_NO_SUCH_USER", "localAddress": null, "remoteAddress": "ipv4:10.3.20.3:60672", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "nfs/backupserver1.example.com@EXAMPLE.COM", "workstation": null, "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": null, "mappedDomain": null, "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": null, "duration": 2367}}
Besides the requesting SPN not being found, it is strange that the log lines state that the client is the IP 10.3.30.100 which is a completely different machine. At least, later in the lines it shows the actual IP 10.3.20.3.
I can concur that my kinit requests reaches the correct kdc. But I don’t understand why the SPN is not found. I see that the request is for krbtgt/EXAMPLE.COM@EXAMPLE.COM (line 2) which might or might not be wrong but I ran my kinit request also with parameter -S backupserver1$ with the same result besides the request now being for backupserver1$@EXAMPLE.COM.