Hi all,
I'm currently trying to setup SSO in our company using MIT Kerberos. We have a
KDC (on xyz.realm.com), some kerberized applications (uvw.realm.com ;
rst.realm.com ; ...) and all theses Virtual Machines are on a VPN (checkpoint
SNX). Some users (principal: [email protected] ; [email protected] ;
root/[email protected] ; ...) and kerberized applications (principal:
HTTP/[email protected] ; HTTP/[email protected] ; ...) are
registered in the KDC.
All kerberized applications and the KDC are in Linux VM on the VPN. All
/etc/krb5.conf and C:/ProgramData/MIT/Kerberos5/krb5.ini files have the
following content:
[libdefaults]
default_realm = REALM.COM
[realms]
REALM.COM = {
kdc = xyz.realm.com:88
admin_server = xyz.realm.com:749
default_domain = realm.com
}
[domain_realm]
.realm.com = REALM.COM
realm.com = REALM.COM
>From a Windows client (with MIT Kerberos) or a Unix client (in fact it's a VM
>on the VPN because I don't have a Linux physical machine), I can get an
>initial ticket with Kinit. The log file of the KDC show the following line:
Jan 16 15:53:44 xyz.realm.com krb5kdc[1767](info): AS_REQ (7 etypes {18 17 16
23 1 3 2}) <VPN Internal IP>: ISSUE: authtime 1389884024, etypes {rep=18 tkt=18
ses=18}, [email protected] for krbtgt/[email protected]
* Unix client:
F rom a Unix client, I can execute a Klist command to see that I have a valid
ticket (expires in 10h). So the next step is to access to the kerberized
application with a web browser. In Mozilla Firefox, I've set the following
configuration:
* network.negotiate-auth.delegation-uris user set string .REALM.COM
* network.negotiate-auth.trusted-uris user set string .REALM.COM
* network.negotiate-auth.using-native-gsslib user set boolean false
Then I access to http://uvw.realm.com and miracle, I'm connected. The KDC log
file show the following lines:
Jan 16 16:10:51 xyz.realm.com krb5kdc[1767](info): TGS_REQ (4 etypes {18 17 16
23}) <Client IP>: ISSUE: authtime 1389885003, etypes {rep=18 tkt=18 ses=18},
[email protected] for HTTP/[email protected]
Jan 16 16:10:51 xyz.realm.com krb5kdc[1767](info): TGS_REQ (1 etypes {18})
<Client IP>: ISSUE: authtime 1389885003, etypes {rep=18 tkt=18 ses=18},
[email protected] for krbtgt/[email protected]
The kerberized application log file (apache error.log) show the following:
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1628): [client <Client
IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1628): [client <Client
IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1240): [client <Client
IP>] Acquiring creds for HTTP/[email protected]
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1385): [client <Client
IP>] Verifying client data using KRB5 GSS-API
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1401): [client <Client
IP>] Client delegated us their credential
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1420): [client <Client
IP>] GSS-API token of length 22 bytes will be sent back
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1628): [client <Client
IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos,
referer: http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1240): [client <Client
IP>] Acquiring creds for HTTP/[email protected], referer:
http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1385): [client <Client
IP>] Verifying client data using KRB5 GSS-API , referer: http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1401): [client <Client
IP>] Client delegated us their credential, referer: http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1420): [client <Client
IP>] GSS-API token of length 22 bytes will be sent back, referer:
http://uvw.realm.com/
* Windows client:
>From a Windows client, I can use MIT Kerberos to get the initial ticket for
>[email protected] (expires in 10h too). The KDC log file show the same line than
>from a Unix client. I've set the same configuration in the about:config of
>Firefox but when I tried to access to http://uvw.realm.com, I'm not connected.
>The log file of the KDC doesn't say anything, there is no TGS_REQ.
So I checked the kerberized application log file (apache error.log):
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN
Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type
Kerberos
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN
Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type
Kerberos
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1240): [client <VPN
Internal IP>] Acquiring creds for HTTP/[email protected]
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1385): [client <VPN
Internal IP>] Verifying client data using KRB5 GSS-API
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1401): [client <VPN
Internal IP>] Client didn't delegate us their credential
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1429): [client <VPN
Internal IP>] Warning: received token seems to be NTLM, which isn't supported
by the Kerberos module. Check your IE configuration.
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1101): [client <VPN
Internal IP>] GSS-API major_status:00010000, minor_status:00000000
[Thu Jan 16 16:19:12 2014] [error] [client <VPN Internal IP>]
gss_accept_sec_context() failed: An unsupported mechanism was requested (,
Unknown error)
I don't understand what I'm doing wrong... It would be wonderful if someone
could help me to resolve this issue! We don't have Active Directory (Windows
client belongs to Workgroup:WORKGROUP) and no entries have been set to the DNS
as we use krb5.conf/krb5.ini for this test infrastructure.
Regards,
Morgan
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
