a colleague just got a response from Apple, as to why safari kerb.auth didn't work with this module - and the reason according to the safari devs is that safari insists on sending the servicename (ie. HTTP/server@realm) as lowercase (ie. http/server@realm) - so if the modgssapache module could just "ignore" case in the servicename, it should work with safari too.
Any ideas where to look for this in the module?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
/* XXX add an configuration option for service name specification */
input_token.value = "HTTP";
input_token.length = 5;
It is not a simple string compare ! I have to add an option to give for example a list of possible service names and loop over the gss_import/gss_acquire block.
HTTP,http,xxx
But I have to think if the service name is used somewhere. I also don't know if you have to have akeytab with a http an HTTP entry and I don't know if MS will be able to have a HTTP and http entry in AD as MS is often blind in respect to case.
Thanks
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
do you get the below in your apache error log(you may need to set the right log level in httpd.conf) ?
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] Use service principal http
[Tue Apr 26 12:50:38 2005] [notice] [client 10.128.53.232] gss_acquire_cred() failed for service principal: No principal in keytab matches desired name: http
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] Use service principal HTTP
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] GSSAPI Warning: no replay protection !
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] GSSAPI Warning: no sequence protection !
What you would need to do is create a SPN with a lowercase service name e.g. http/fqdn and add this key into your keytab. Unfortunatly the service name is case sensitive.
Regards
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I set loglevel to debug and got what you said - then I added a user and a new entry in the keytab (does the reverse lookup have to match the same name btw.?) but I get this:
[Thu Apr 28 15:27:17 2005] [info] [client x.x.x.x] Use service principal http
[Thu Apr 28 15:27:17 2005] [notice] [client x.x.x.x] gss_acquire_cred() failed: No principal in keytab matches desired name: Used service principal: http
I also tried making a keytab exactly the same as the one that works in IE and firefox, with HTTP in lowercase - but that makes it ask for password, and give the above error in the log.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the klist on the apple did show a lowercase http - but as mentioned I had tried the "copy key" trick you gave :)
I'll add another user, and see if that works now when I have not made a mistake in the tickets of some sorts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The do a ktutil with the following commands:
#ktutil
ktutil: addent -key -p http/moelma.test.com@TEST.COM -k 1 -e rc4-hmac
Key for http/moelma.test.com@TEST.COM (hex): 0d41ede68082fc5b8611dc5da75b5d4f
ktutil: wkt /etc/HTTP.keytab
ktutil: quit
Use the same kvno and enc-type as the HTTP entry. This should create a second entry (with the service name http) to the keytab with the same key as for the HTTP service.
Could you let me know if it works
Thanks
Markus.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm guessing it's because I need to have a user in the AD which is mapped to the lowercase servicename..
I made a mistake before so I couldn't log in at all - I just recreated the user, and now I can get in with the HTTP service version. will try to create an extra user - for the http service version - not right now though - Safari isn't that important :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think one of the problems is taht AD doesn't differentiate between HTTP and http.
In the case AD has a HTTP/fqdn principal and IE asks for a TGS it gives back the HTTP/fqdn principal key. If the Mac asks for a TGS AD gives back the same key but with the http/fqdn principal name.
This is why I think you shouldn't create a second entry in AD as AD might get confused, adn the method I described should work ( at least it worked for me in my limited setup).
Regards
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried your method (and have it running right now) - and the OS X gets the http ticket - but it now allowed in - an error 108. Want me to email the caught tickets?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I remember right 108 means only that it is not a spnego token and I continue in the code assuming it to be a gssapi token to be used in accept_sec_context, which would give an error if it is not a gssapi token either. Did you see a gss_accept_sec_context error ?
Regards
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys,
a colleague just got a response from Apple, as to why safari kerb.auth didn't work with this module - and the reason according to the safari devs is that safari insists on sending the servicename (ie. HTTP/server@realm) as lowercase (ie. http/server@realm) - so if the modgssapache module could just "ignore" case in the servicename, it should work with safari too.
Any ideas where to look for this in the module?
Klavs,
look for the following:
/* XXX add an configuration option for service name specification */
input_token.value = "HTTP";
input_token.length = 5;
It is not a simple string compare ! I have to add an option to give for example a list of possible service names and loop over the gss_import/gss_acquire block.
HTTP,http,xxx
But I have to think if the service name is used somewhere. I also don't know if you have to have akeytab with a http an HTTP entry and I don't know if MS will be able to have a HTTP and http entry in AD as MS is often blind in respect to case.
Thanks
Markus
Klavs,
can you check if this works for you ?
http://sourceforge.net/tracker/index.php?func=detail&aid=1190309&group_id=82781&atid=567192
Thanks
Markus
I just tested it - but safari still fails with a rc=109. Any debug info I can give you?
Klavs,
do you get the below in your apache error log(you may need to set the right log level in httpd.conf) ?
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] Use service principal http
[Tue Apr 26 12:50:38 2005] [notice] [client 10.128.53.232] gss_acquire_cred() failed for service principal: No principal in keytab matches desired name: http
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] Use service principal HTTP
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] GSSAPI Warning: no replay protection !
[Tue Apr 26 12:50:38 2005] [info] [client 10.12.5.32] GSSAPI Warning: no sequence protection !
What you would need to do is create a SPN with a lowercase service name e.g. http/fqdn and add this key into your keytab. Unfortunatly the service name is case sensitive.
Regards
Markus
I set loglevel to debug and got what you said - then I added a user and a new entry in the keytab (does the reverse lookup have to match the same name btw.?) but I get this:
[Thu Apr 28 15:27:17 2005] [info] [client x.x.x.x] Use service principal http
[Thu Apr 28 15:27:17 2005] [notice] [client x.x.x.x] gss_acquire_cred() failed: No principal in keytab matches desired name: Used service principal: http
I also tried making a keytab exactly the same as the one that works in IE and firefox, with HTTP in lowercase - but that makes it ask for password, and give the above error in the log.
Any ideas?
From where does the Mac Safari Browser get the Kerberos ticket ?
Does the klist show a lower case http ? Do you have in AD a lowercase http and uppercase HTTP service principal ?
Can you capture the communication between your browsers (Mac and Windows) and the kdc ? It will contain the principal names requested.
Regards
Markus
the klist on the apple did show a lowercase http - but as mentioned I had tried the "copy key" trick you gave :)
I'll add another user, and see if that works now when I have not made a mistake in the tickets of some sorts.
Klavs,
can you do the following on your web server (I assuming you use MIT Kerberos):
# klist -k -e -K -t /etc/HTTP.keytab
Keytab name: FILE:/etc/httpd/HTTP.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
1 11/29/04 11:42:25 HTTP/moelma.test.com@TEST.COM (ArcFour with HMAC/md5) (0x0d41ede68082fc5b8611dc5da75b5d4f)
The do a ktutil with the following commands:
#ktutil
ktutil: addent -key -p http/moelma.test.com@TEST.COM -k 1 -e rc4-hmac
Key for http/moelma.test.com@TEST.COM (hex): 0d41ede68082fc5b8611dc5da75b5d4f
ktutil: wkt /etc/HTTP.keytab
ktutil: quit
Use the same kvno and enc-type as the HTTP entry. This should create a second entry (with the service name http) to the keytab with the same key as for the HTTP service.
Could you let me know if it works
Thanks
Markus.
parseNegTokenInit failed with rc=108
ie. it didn't work :)
I'm guessing it's because I need to have a user in the AD which is mapped to the lowercase servicename..
I made a mistake before so I couldn't log in at all - I just recreated the user, and now I can get in with the HTTP service version. will try to create an extra user - for the http service version - not right now though - Safari isn't that important :)
I think one of the problems is taht AD doesn't differentiate between HTTP and http.
In the case AD has a HTTP/fqdn principal and IE asks for a TGS it gives back the HTTP/fqdn principal key. If the Mac asks for a TGS AD gives back the same key but with the http/fqdn principal name.
This is why I think you shouldn't create a second entry in AD as AD might get confused, adn the method I described should work ( at least it worked for me in my limited setup).
Regards
Markus
I tried your method (and have it running right now) - and the OS X gets the http ticket - but it now allowed in - an error 108. Want me to email the caught tickets?
If you could sent me the ticket that would be very helpful.
Thanks
Markus
Do you get any other message then error 108 ?
If I remember right 108 means only that it is not a spnego token and I continue in the code assuming it to be a gssapi token to be used in accept_sec_context, which would give an error if it is not a gssapi token either. Did you see a gss_accept_sec_context error ?
Regards
Markus