Skip to main content
Super User

Return to Answer

added 373 characters in body
Source Link
grawity_u1686
grawity_u1686
  • 465.3k
  • 66
  • 977
  • 1.1k

Kerberos, much like TLS, requires the specified hostnameyou to matchconnect to a hostname that matches the server's configuration – an IP address will generally not work.

 

It doesn't end at "getting a ticket" in general – you also need to get a ticket for the specific service that you're authenticating to. Each service has its own key shared with the Kerberos KDC, identified by "service principal name" such as cifs/nas.example.com for an SMB file server or HTTP/blog for a webapp (or indeed krbtgt/EXAMPLE.COM for the "ticket issuance" service). When things go right, the 'mount' command will get the service ticket automatically and it'll show up in klist:

  1. Look up a DC name:

    host -t srv _ldap._tcp.example.com    => dc01.example.com

  2. Search for SPNs of non-Windows servers:

    ldapsearch -H ldap://dc01.example.com -Y GSS-SPNEGO -Q \
           '(&(objectCategory=computer)(!(operatingSystem=Windows*)))' \
           servicePrincipalName \
           | grep -i '\bhost/' | sort -f

Kerberos, much like TLS, requires the specified hostname to match the server's configuration – an IP address will generally not work.

It doesn't end at "getting a ticket" in general – you also need to get a ticket for the specific service that you're authenticating to. Each service has its own key shared with the Kerberos KDC, identified by "service principal name" such as cifs/nas.example.com for an SMB file server or HTTP/blog for a webapp (or indeed krbtgt/EXAMPLE.COM for the "ticket issuance" service).

Kerberos, much like TLS, requires you to connect to a hostname that matches the server's configuration – an IP address will generally not work.

 

It doesn't end at "getting a ticket" in general – you also need to get a ticket for the specific service that you're authenticating to. Each service has its own key shared with the Kerberos KDC, identified by "service principal name" such as cifs/nas.example.com for an SMB file server or HTTP/blog for a webapp (or indeed krbtgt/EXAMPLE.COM for the "ticket issuance" service). When things go right, the 'mount' command will get the service ticket automatically and it'll show up in klist:

  1. Look up a DC name:

    host -t srv _ldap._tcp.example.com    => dc01.example.com

  2. Search for SPNs of non-Windows servers:

    ldapsearch -H ldap://dc01.example.com -Y GSS-SPNEGO -Q \
           '(&(objectCategory=computer)(!(operatingSystem=Windows*)))' \
           servicePrincipalName \
           | grep -i '\bhost/' | sort -f
Source Link
grawity_u1686
grawity_u1686
  • 465.3k
  • 66
  • 977
  • 1.1k

Kerberos, much like TLS, requires the specified hostname to match the server's configuration – an IP address will generally not work.

It doesn't end at "getting a ticket" in general – you also need to get a ticket for the specific service that you're authenticating to. Each service has its own key shared with the Kerberos KDC, identified by "service principal name" such as cifs/nas.example.com for an SMB file server or HTTP/blog for a webapp (or indeed krbtgt/EXAMPLE.COM for the "ticket issuance" service).

$ klist
Valid starting       Expires              Service principal
04/09/2024 17:52:46  04/10/2024 03:39:06  krbtgt/[email protected]
04/09/2024 18:00:02  04/10/2024 03:39:06  HTTP/[email protected]
04/09/2024 18:00:02  04/10/2024 03:39:06  nfs/[email protected]
04/09/2024 18:00:05  04/10/2024 03:39:06  imap/[email protected]
04/09/2024 18:00:05  04/10/2024 03:39:06  host/[email protected]
04/09/2024 18:00:06  04/10/2024 03:39:06  nfs/[email protected]

This means that, in order the client to successfully get tickets for the correct Kerberos service, it needs to be given the correct hostname or subdomain name that the KDC knows for that service – any random address will not work.

The generic "Required key not available" error code comes from the 'cifs.upcall' program failing to get a ticket; you can see the more detailed error messages in your syslog or system journal (journalctl).

(Linux Kerberos sometimes makes it work by using 'reverse DNS' to look up the hostname from IP address via PTR records, but most networks do not have rDNS available for their internal IPs.)

When servers are joined to AD, their computer accounts automatically get SPNs for their full domain name cifs/nas02.example.com and their short computer name cifs/nas02, but not for their IP address (and also not for any manually-created DNS CNAME aliases). So you need to find out what the "real" AD hostname of the Synology NAS is, and then use that in your 'mount' command.

You can usually look up computer SPNs in Active Directory through LDAP with ldapsearch (unless the AD admins have deliberately hidden them), or you can manually guess at possible SPNs using the kvno tool (e.g. kvno cifs/[email protected]).