Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

problem when configuring sso to linux-systems with an W2k8-DC

Former Member
0 Kudos

Hello community,

we are planing to update our Windows domain controllers to Windows 2008 and i am responsible to test the SSO to our SAP-Systems.

For the systems running on a windows server, it was no problem. But the ones running under linux are causing some trouble and i cannot find a solution in SDN/SAPNet, with google or anywhere else. And so i'm starting a new thread for this.

Here is my test scenario:

name of domain: company.internal

name of W2k8-dc: dc2008

name of sap-server: sap15

sap-system-id: PUD

Here are the steps i have performed so far, mostly following a whitepaper from realtech which is linked to in other threads concerning sso/active directory/linux.

- create the user pudadm in the AD on dc2008 (cannot change password, password never expires)

- create a SPN with

setspn -A SAP_PUD/sap15.company.internal COMPANY\pudadm

"COMPANY\pudadm" is the user logon name for pre-windows 2000 systems

- create a keytab with

ktpass -princ SAP_PUD/sap15.company.internal @ COMPANY.INTERNAL -mapuser COMPANY\pudadm -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -pass <password for pudadm> -out sap.keytab

Output looks ok, and i copy this file to /tmp on sap15 the linux-server.

As root on sap15 i copy the key from sap.keytab to /etc/krb5.keytab by using ktutil (rkt / wkt). With ktutil i can see that there is no problem for this step, the key is properly copied to /etc/krb5.keytab. When i list the key with ktutil, the vno value is the same as the one in the output when creating the keytab file on dc2008.

Still being root, i try to get a ticket granting ticket and enter

kinit -V -k SAP_PUD/sap15.company.internal @ COMPANY.INTERNAL

and get the error "Key table entry not found while getting initial credentials". Which means, as far as i know, that either the host or the user is not listed in the keytab file.

I tried some other combinations with company.internal, COMPANY.INTERNAL or just COMPANY and so on, but had no luck.

Any help would be appreciated.

Thanks and reagrds,

ulf

p.s.:

- the blanks before and afther the @ are just here, beause of forum rules

- /etc/krb5.conf is configured

- i know about sap note 1292886 and the microsoft patch is already applied to the dc2008

1 ACCEPTED SOLUTION

tim_alsop
Active Contributor
0 Kudos

Hi,

When you checked your keytab using ktutil, you mentioned that you checked the key version number (vno) but you didn't mention that you checked the principal name of the key. The principal name of the key in the keytab is what you need to enter when you use kinit -k

Thanks,

Tim

8 REPLIES 8

tim_alsop
Active Contributor
0 Kudos

Hi,

When you checked your keytab using ktutil, you mentioned that you checked the key version number (vno) but you didn't mention that you checked the principal name of the key. The principal name of the key in the keytab is what you need to enter when you use kinit -k

Thanks,

Tim

Former Member
0 Kudos

Hi Tim,

i mentioned the number because it was explicitly mentioned in the whitepaper.

The principal name in the key and in the kinit is the same (including all lower- and uppercase domain names and so on).

Regards,

ulf

tim_alsop
Active Contributor
0 Kudos

If the principal name used with kinit is same as in keytab then you would not get this error, so they must be different. Perhaps the keytab file you put the key into is not same keytab that is used by kinit ?

Here's how it works for me on a REDHAT EL5 Linux Server. My realm is DEV.LOCAL (domain name = dev.local):

First I create the keytab:


[root@shrek ~]# ktutil -t WFILE:/tmp/keytab -e RC4 -x SAP_PUD/sap15.company.internal @ DEV.LOCAL
Active Directory Administrator Account: talsop @ DEV.LOCAL
Password:
[root@shrek ~]#

Then I use ktutil to show keytab contents and confirm it is as expected:


[root@shrek ~]# ktutil -t FILE:/tmp/keytab
      Key Table File: /tmp/keytab

KVNO  EType  Timestamp                     Principal
----  -----  ----------------------------  ---------
   3    23   Wed 04 Nov 2009 16:35:57 GMT  SAP_PUD/sap15.company.internal @ DEV.LOCAL
   3    24   Wed 04 Nov 2009 16:35:57 GMT  SAP_PUD/sap15.company.internal @ DEV.LOCAL
[root@shrek ~]#

Next, I use kinit to check the key in keytab can be used to get an initial ticket.


[root@shrek ~]# kinit -t FILE:/tmp/keytab -k SAP_PUD/sap15.company.internal @ DEV.LOCAL
[root@shrek ~]#

As you can see, it works without any errors.

Next, I check ticket in cred cache using klist


[root@shrek ~]# klist
          Cache Type: Kerberos V5 Credentials Cache
          Cache File: /krb5/tmp/cc/krb5cc_0
       Cache Version: 0502
   Default Principal: SAP_PUD/sap15.company.internal @ DEV.LOCAL

Valid From                    Expires                       Service Principal
----------------------------  ----------------------------  -----------------
Wed 04 Nov 2009 16:34:16 GMT  Thu 05 Nov 2009 00:37:53 GMT  krbtgt/DEV.LOCAL @ DEV.LOCAL
[root@shrek ~]#

I hope this example helps ? As you can see, I used RC4 keys and not a DES key - this is because DES is not best etype to use, especially now that with Windows 7 the DES etype has been disabled by default and many implementations of Kerberos are having DES support removed, since it is considered weak. Also, RC4 is default etype in MS AD, and in fact, with Windows Server 2008 version of AD it is preferred to use AES and not DES or RC4.

Thanks,

Tim

Former Member
0 Kudos

Hi Tim,

thanks for your help so far!

I'm afraid, the principal name in the keytab-file and the one used in the kinit command are the same. I read some threads here and i know that this error should not happen, that's what's driving me crazy here

Here is what i did to be sure the names are the same:

1. delete the /etc/krb5.keytab

2. create the sap.keytab on the dc and transfer it to the linux-server

3. call ktutil and read the key in the sap.keytab. The principal has the name SAP_PUD/company.internal @ COMPANY.INTERNAL ( i created a new one without sap15)

4. wkt /etc/krb5.keytab

5. quit ktutil, call it again (to clear the keylist, i know it can be done easier)

6. read the /etc/krb5.keytab, list the key and i can see, that the key is the one from the sap.keytab

Until here, everything is as i expect it to be

Then i use

"kinit -k -t /etc/krb5.keytab SAP_PUD/company.internal @ COMPANY.INTERNAL"

and the result is

"kinit(v5): Key table entry not found while getting initial credentials"

Which is kind of expected after all my trys but which is surely not what it should be.

If i call "kinit SAP_PUD/company.internal @ COMPANY.INTERNAL"i get a prompt for the password and a ticket is granted. "klist -k" shows the SAP_PUD/company.internal @ COMPANY.INTERNAL in /etc/krb5.keytab.

I have compared this with a running implementation on another server and for root the tickets look the same in klist.

So i have tried to get a ticket for pudadm and i get

su - pudadm

kinit -k -t /etc/krb5.keytab SAP_PUD/company.internal @ COMPANY.INTERNAL

Exception: krb_error 0 Cannot retrieve key from keytab for principal SAP_PUD/company.internal @ COMPANY.INTERNAL No error

KrbException: Cannot retrieve key from keytab for principal SAP_PUD/company.internal @ COMPANY.INTERNAL

at sun.security.krb5.internal.tools.Kinit.<init>(DashoA12275:199)

at sun.security.krb5.internal.tools.Kinit.main(DashoA12275:109)

Java-Version is 1.4.2_13, i wonder if that is a problem. Looks pretty old to me but on the other hand SAP is very picky concerning the java version.

Regards, ulf

tim_alsop
Active Contributor
0 Kudos

Hi,

I bet thsi is because of a bug in the Kerberos libraries you are using, and perhaps the _ in the principal name is causing the issue. I bet if you use a different principal name and don't use the _ then it will work.

Not sure why you are mentioning Java since you are not using a Java Kerberos library.

If you need help with Kerberos libraries then you need to get help from the vendor of those libraries. So far, nothing you have explained suggests any SAP software is being used - the SAP software is only used later when you have confirmed the keytab is working with kinit -k and you then start SAP to use the GSS library.

I hope you are aware that there sare commercially supported versions of SNC libraries avaialble for linux and then the vendor you work with has the experience and knowledge of how to set this up and support your SAP systems when they are using Kerberos for authentication.

Thanks,

Tim

Former Member
0 Kudos

Hi Tim,

i have tried it with a different spn (no _ or - in the name, just sapsso) and still get the error.

I mentioned java, because google gave me some search results where the java-version was mentioned. If this is not a java problem, the better for us, one less field to look at.

Our kerberos packages are old, though. May be an update on them will help us.

Next step i will do is implement sso in our normal environment with windows 2000 as domain cntrollers. I want to see if this works when i do all the configurations or if i do something wrong. As this is not my normal field of work, i don't have much experience on that. As you may have noticed ;). If it works, i will update the kerberos packages on the linux server. But this will not happend today.

And yes, we are aware of the commercial solutions and i know the price of at least one of them. For use in our internal systems it's just too expensive. Even more, when you have a running solution with open source.

Regards,

ulf

tim_alsop
Active Contributor
0 Kudos

Ulf,

I can guarantee that using Windows 2000 domain controllers is not going to change anything. The problem you are having is locat to the linux host, since this error means that kinit cannot find the principal entry in the keytab - it hasn't even got as far as sending the as-req to the KDC (e.g. Active Directory).

Regarding prices and commercial products - If you are intersted, I can give you a very competitive price quote.

- Please remember that the cost is more than license costs when comparing open source Kerberos with commercially supported implementations. You also need to consider people cost and support. Look at how long it is taking you to make this work and the cost of your time ? If you are having difficulty with this now and then later your company deploys this solution, what happens if nobody can logon because of a broken Kerberos library ? Who do you get help from ?

Thanks,

Tim

Former Member
0 Kudos

i have worked on this every now and then in the past weeks and finally it looks as if it is working.

As i have changed and tested many things, i can't remember everything but i want to give some clues where to look in case of problems before closing this answer.

1. Pay very much attention on the ktpass-tool and how you call it. I fogot to set the -crypto parameter and it looks this was one reason for problems. I found the hint to check the encryption type in the keytab and in the ticket when i had the 'integrity check failure' and after creating a new keytab with explicitly 2-crypto DES-CBC-CRC" in the command it worked.

2. Check your server time. This is obvious and normally all servers should get their time from one NTP-erver

3. Check your syntax when entering commands. One time i entered "kinit ... SAPService/company.intern/COMPANY.INTERN" and thought the error would be in the krb5.conf. After editing i used the cursor keys to get the comand again and of course it did not work.

4. With SLES SP3 it seems to be easier. I still have the problem, that on the SLES SP2 systems kinit will not get the ticket automatically. I have to call 'kinit SAPService/company.intern (at) COMPANY.INTERN' and get a prompt for the password. On SLES SP3 i call 'kinit -k -t <keytab> SAPService/company.intern (at) COMPANY.INTERN' and get the new ticket. I don't know if the SP3 does the trick, we will update our systems soon, but for the moment we can live with that.

Conclusion: I don't now how many hours i spent on this. I would not say it is wasted time, because i learned a lot about kerberos and SSO. If you want a stable solution out of the box and have some money to spend, i'd recommend a 3rd-party-tool though. But if you have time and no pressure, try it with MIT-kerberos.

Regards,

ulf