2

i'm working on very annoying issue, namely our java app on redhat 7 is created to connect to mssql, which cannot parse principal stored in keytab generated by our company automats. Principal stored in keytab: svcAccount/fqdn@RELM

For tests, i generated cCache using following command

kinit -f -c -p FILENAME svcAccount@REALM

This kind of conncection config works fine, as principal stored in cCache has syntax understable for microsoft apps, however when i'm trying to esablish connection with keytab in use i receive following error:

**com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user 
'domain\ svcAccount/fqdn '**

I've tried add "auth_to_local" into KRB5.conf but it seems that kerberos omit this config.

Any idea how to map this principal name on windows server? do i have to modify it in my java application or it's just wrong kerberos configuration? To make it more difficult: i don't have rights to kadmin, to modify keytab :/


KERBEROS CONFIGURATION:

Klist –kte keytab.file:

KVNO Timestamp           Principal

   3 12/31/1969 19:00:00 svcAccount/fqdn@RELM (encryption method)

   3 12/31/1969 19:00:00 svcAccount/fqdn@RELM (encryption method)

   3 12/31/1969 19:00:00 svcAccount/fqdn@RELM (encryption method)

SQLJDBCDriver.conf

SQLJDBCDriver {

com.sun.security.auth.module.Krb5LoginModule required

useKeyTab=true

keyTab="FILE:/home/filename.keytab"

principal=" svcAccount/fqdn@RELM "

storeKye=true

debug=true

credsType=both

doNotPrompt=true;

};

Java starts with arguments

JAVA_OPTS="-Dspring.jmx.enabled=false -Dkerberos.client.reference.name=SQLJDBCDriver -Djava.security.auth.login.config=/etc/path/SQLJDBCDriver.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.krb5.debug=true -Djava.security.krb5.conf=/etc/krb5.conf -Dspring.profiles.active=uat"

Connection string:

url: jdbc:sqlserver://serverName:2431;databaseName=DB_NAME;integratedSecurity=true;authenticationScheme=JavaKerberos;serverSpn=MSSQLSvc/fqdn:2431@DOMAIN

KRB5.CONF

[libdefaults]

  default_realm = DOMAIN.COM

  default_ccache_name = KEYRING:persistent:%{uid}

  dns_lookup_realm = true

  dns_lookup_kdc = true

  noaddresses = true

  kdc_timesync = 0

  rdns = false

  kdc_timeout = X

  max_retries = X

  ticket_lifetime = XX

  renew_lifetime = XX



[realms]

    DOMAIN.COM = {

    }



[domain_realm]

   domain.com = DOMAIN.COM

[appdefaults]

       pam = {

               validate = true

               keytab = /etc/krb5.keytab

               banner = login

               minimum_uid = X

               addressless = X

               use_shmem = tX

               ignore_unknown_principals = X

       }

       kinit = {

               renewable = true

               forwardable= true

       }
0
**com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user
'domain\ svcAccount/fqdn '**

Note the spaces both before and after svcAccount/fqdn.

In SQLJDBCDriver.conf, those spaces also exist within the double quotes:

principal=" svcAccount/fqdn@RELM "

svcAccount is not the same as <space>svcAccount, and RELM<space> is not the same as RELM. Remove the extra spaces in SQLJDBCDriver.conf and try again.

Also, the [domain_realm] section of your krb5.conf file might or might not need one or both of the following lines:

domain = RELM
.domain = RELM
0

Thanks for reply but these spaces I made mistakenly while preparing post. I don't think it's matter of "domain" lines since i can stablish connection using hardcoded username and password in connection string and also using cCache file, what means that krb5.conf allow establish connection, but kerberos doesn't translate principal to understandable for microsoft services.

I would like just add that i finaly established connection.

Solution: download krb5 server with all tools [ktutil kinit kadmin etc], add principal in following convenction: principal@REALM, and save as already created keytab [new entries will be appended]. .. and that's it :) i know it's bypass but works.. i hope it will be useful, as kerberos is nightmare. name of this technology is adequate... it prevents from performing quick configuration :D

thread can be closed

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.