I am trying to configure a keytab file to use with my service principal for Kerberos authentication between my Linux (RHEL9) server and my Microsoft Windows 2022 Server. The service principal is MSSQLSvc/[email protected]. When I generate the keytab file on my AD host (controller) and then upload it to my RHEL host and attempt to generate a ticket.
kinit -V -t /etc/test.keytab MSSQLSvc/[email protected]
I always gets:
Using keytab: /etc/test.keytab
kinit: Invalid integer value while getting initial credentials
Also tried:
kinit MSSQLSvc/[email protected]
kinit: Invalid integer value while getting initial credentials
Here’s the background of how I configured my environment. First, I set my SQL Server service to run with my domain user [email protected]. I then generated a service principle for my user:
PS C:UsersAdministrator> setSPN EvolvenDBUser
Registered ServicePrincipalNames for CN=EvolvenDBUser,CN=Users,DC=evolven,DC=corp:
MSSQLSvc/MSSQL-G1CFTVE.evolven.corp
MSSQLSvc/MSSQL-G1CFTVE.evolven.corp:1433
Next, I then generated a keytab file on my AD host via this command:
ktpass -princ MSSQLSvc/[email protected] -mapuser [email protected] -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass <password> -out test.keytab -SetPass
It returns this:
Targeting domain controller: EC2AMAZ-AEHRC46.evolven.corp
Using legacy password setting method
Successfully mapped MSSQLSvc/MSSQL-G1CFTVE.evolven.corp to EvolvenDBUser.
Key created.
Output keytab to evolven.keytab:
Keytab version: 0x502
keysize 99 MSSQLSvc/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x12 (AES256-SHA1) keylength 32 (0x0a32866cd2364109a006b483cedd8f6eee418f87b2b460d6be75e6763b1b0aef)
When I examine they keytab file on my RHEL host:
klist -k /etc/test.keytab
Keytab name: FILE:/etc/test.keytab
KVNO Principal
---- --------------------------------------------------------------------------
18 MSSQLSvc/[email protected]
On my RHEL host, my krb5.conf isn’t super fancy but I can confirm it supports the encryption settings I want to use.
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = EVOLVEN.CORP
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 30d
renew_lifetime = 30d
forwardable = true
udp_preference_limit = 1 # Forces TCP if UDP fails
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
[realms]
EVOLVEN.CORP = {
kdc = EC2AMAZ-AEHRC46.evolven.corp
admin_server = EC2AMAZ-AEHRC46.evolven.corp
}
[domain_realm]
.evolven.corp = EVOLVEN.CORP
evolven.corp = EVOLVEN.CORP
I’ve tried many things:
- I have enabled user supports AES-128 and AES-256 in AD.
- Changed the password of the AD user and then regenerated the keytab file. I also removed special characters in the password thinking that it be might be causing an issue. Still the samne.
- Did a kdestroy to remove all old tickets.
- I saw a post here: kinit: Preauthentication failed while getting initial credentials.
- Not sure why, but I do not see any logs even though I’ve enabled logging.
I tried to do: ktutil: add_entry -password -p MSSQLSvc/[email protected] -k 18 -e aes256-cts-hmac-sha1-96 -f
and I get back
add_entry: Invalid integer value while adding new entry
So something is clearly wrong here with my service principle authentication. What do I do to resolve so I can generate tickets?
4
Invalid integer is an error that occurs during krb5.conf parsing. Most likely this is because of your udp_preference_limit, which is set to 1 # Forces TCP if UDP fails – that’s not a valid number, as krb5.conf does not support same-line comments.
That aside: You have two entities (client and service) but only one AD account between both, and this is not how you’re supposed to use Kerberos.
As a general rule, clients for a service should never be using the same principal as the service – you should create a dedicated user account (without an SPN) for each client.
(When you do kinit MSSQLSvc/MSSQL-whatever, you aren’t getting tickets for the MSSQL server – you’re getting tickets as the MSSQL server, which is the opposite of what you’re probably trying to do.)
Keep in mind that a keytab is literally the account’s password in different form, so if you normally wouldn’t tell clients the service account’s password, then you shouldn’t be giving clients a service keytab either. (Much like you also wouldn’t give webapp users a copy of the server’s HTTPS private key…)
7