SSO Linux --> AD using GSSAPI
SANDERS Miguel
miguel.sanders at arcelormittal.com
Fri Nov 26 15:26:41 EST 2010
If you have the proper kerberos SRV records, just create a key under domains (LOCAL.CA) and set RealmFlags to 6 (4 = delegation, 2 = TCP support).
The TCP support might come in handy if the embedded PACs are getting too large.
After that, reboot the client.
Good luck!
Met vriendelijke groet
Best regards
Bien à vous
Miguel SANDERS
ArcelorMittal Gent
UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent
T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023
E miguel.sanders at arcelormittal.com
www.arcelormittal.com/gent
>P Please consider the environment before printing this e-mail
-----Oorspronkelijk bericht-----
Van: Carter, Joel [mailto:JoelC at trailerwizards.com]
Verzonden: vrijdag 26 november 2010 21:20
Aan: SANDERS Miguel; kerberos at mit.edu
Onderwerp: RE: SSO Linux --> AD using GSSAPI
Thank you for your help.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\ doesn't have any key or values under it.
Shall I create one on a DC for LOCAL.CA set to 4?
Joel.
-----Original Message-----
From: SANDERS Miguel [mailto:miguel.sanders at arcelormittal.com]
Sent: November-26-10 12:13 PM
To: Carter, Joel; kerberos at mit.edu
Subject: RE: SSO Linux --> AD using GSSAPI
Hmm, what value do you have for the RealmFlags in the registry ?
http://technet.microsoft.com/en-us/library/cc736698%28WS.10%29.aspx
Met vriendelijke groet
Best regards
Bien à vous
Miguel SANDERS
ArcelorMittal Gent
UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent
T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023 E miguel.sanders at arcelormittal.com www.arcelormittal.com/gent
>P Please consider the environment before printing this e-mail
-----Oorspronkelijk bericht-----
Van: Carter, Joel [mailto:JoelC at trailerwizards.com]
Verzonden: vrijdag 26 november 2010 21:11
Aan: SANDERS Miguel; kerberos at mit.edu
Onderwerp: RE: SSO Linux --> AD using GSSAPI
Yes I have that checked, no other changes made to PuTTY.
# tail -f /var/log/secure | grep credentials Nov 26 12:08:33 bilbo-rh5 sshd[19970]: debug1: Got no client credentials Nov 26 12:08:33 bilbo-rh5 sshd[19970]: debug1: No credentials stored Nov 26 12:08:33 bilbo-rh5 sshd[19970]: debug1: PAM: establishing credentials Nov 26 12:08:33 bilbo-rh5 sshd[19973]: debug1: PAM: reinitializing credentials
To your knowledge is there anything Windoze-specific delegations or such I need to set to allow the forwarding?
The PuTTY event log shows this:
2010-11-26 12:07:40 Looking up host "bilbo-rh5.local.ca"
2010-11-26 12:07:40 Connecting to 192.168.1.234 port 22
2010-11-26 12:07:40 Server version: SSH-2.0-OpenSSH_4.3
2010-11-26 12:07:40 We claim version: SSH-2.0-PuTTY_Release_0.60_q1.129
2010-11-26 12:07:40 SSPI: acquired credentials for: joelc at LOCAL.CA
2010-11-26 12:07:40 Constructed service principal name 'host/bilbo-rh5.local.ca'
2010-11-26 12:07:40 Enabling GSSKEX for this target
2010-11-26 12:07:40 Using SSH protocol version 2
2010-11-26 12:07:40 Doing Diffie-Hellman group exchange
2010-11-26 12:07:40 Doing Diffie-Hellman key exchange with hash SHA-1
2010-11-26 12:07:40 Host key fingerprint is:
2010-11-26 12:07:40 ssh-rsa 2048 f7:08:54:6a:1a:62:0a:d1:df:0b:f4:37:cd:c3:40:f5
2010-11-26 12:07:40 Initialised AES-256 SDCTR client->server encryption
2010-11-26 12:07:40 Initialised HMAC-SHA1 client->server MAC algorithm
2010-11-26 12:07:40 Initialised AES-256 SDCTR server->client encryption
2010-11-26 12:07:40 Initialised HMAC-SHA1 server->client MAC algorithm
2010-11-26 12:07:40 SSPI: trying user_name='joelc' service=''
2010-11-26 12:07:40 SSPI: acquired credentials for: joelc at LOCAL.CA
2010-11-26 12:07:40 Constructed service principal name 'host/bilbo-rh5.local.ca'
2010-11-26 12:07:41 GSSAPI: system refused to delegate credentials
2010-11-26 12:07:41 Access granted
2010-11-26 12:07:41 Opened channel for session
2010-11-26 12:07:41 Requesting X11 forwarding
2010-11-26 12:07:41 X11 forwarding enabled
2010-11-26 12:07:41 Allocated pty (ospeed 38400bps, ispeed 38400bps)
2010-11-26 12:07:41 Started a shell/command
This doesn't look good: "2010-11-26 12:07:41 GSSAPI: system refused to delegate credentials"
Joel.
-----Original Message-----
From: SANDERS Miguel [mailto:miguel.sanders at arcelormittal.com]
Sent: November-26-10 12:05 PM
To: Carter, Joel; kerberos at mit.edu
Subject: RE: SSO Linux --> AD using GSSAPI
Did you check the "Delegate credentials" in PuTTY? (Connection -> SSH -> GSSAPI)
Met vriendelijke groet
Best regards
Bien à vous
Miguel SANDERS
ArcelorMittal Gent
UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent
T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023 E miguel.sanders at arcelormittal.com www.arcelormittal.com/gent
>P Please consider the environment before printing this e-mail
-----Oorspronkelijk bericht-----
Van: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] Namens Carter, Joel
Verzonden: vrijdag 26 november 2010 20:59
Aan: kerberos at mit.edu
Onderwerp: SSO Linux --> AD using GSSAPI
Hey there.
Been spending a lot of my time recently upgrading our legacy app running on RHEL3 to RHEL5. SSO was previously provided via Winbind, but things seem to be moving away from that. Anyway, I'm almost there but have one last stumbling block.
I have /etc/ldap.conf, /etc/krb5.conf, etc configured and can login using an AD username to RHEL5 successfully. I also get a Kerberos ticket (is that called a delegation?), which I can use further once I'm logged in. This is using PuTTY:
login as: joelc
joelc at bilbo-rh5.local.ca's password:
Last login: Fri Nov 26 11:34:13 2010 from joelc.local.ca
[joelc at bilbo-rh5 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_20001_SwXGUD Default principal: joelc at LOCAL.CA
Valid starting Expires Service principal
11/26/10 11:44:43 11/26/10 21:43:47 krbtgt/LOCAL.CA at LOCAL.CA
renew until 11/26/10 21:44:43
11/26/10 11:43:47 11/26/10 21:43:47 ldap/hawaii.local.ca at LOCAL.CA
renew until 11/26/10 21:44:43
Kerberos 4 ticket cache: /tmp/tkt20001
klist: You have no tickets cached
This is great. Now I can connect back out of RHEL5 to a share as follows which also works:
smbclient -k //oahu/userdata -c "dir"
Now I'm going for the holy grail. I'd like to use GSSAPI in Quest PuTTY (or other GSSAPI-enabled PuTTY if you have a suggestion) so that the user's ticket in Windows is used to authenticate with RHEL5 and no password entry is required. This works, but I don't have a ticket this time.
Using username "joelc".
Using GSSAPI service principal name "host/bilbo-rh5.local.ca".
Last login: Fri Nov 26 11:50:55 2010 from joelc.local.ca
[joelc at bilbo-rh5 ~]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_20001)
Kerberos 4 ticket cache: /tmp/tkt20001
klist: You have no tickets cached
Here's the debug information the sshd daemon dumped during that last
login:
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7 Nov 26 11:53:19 bilbo-rh5 sshd[18149]: debug1: Forked child 19329.
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: inetd sockets after
dupping: 3, 3
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: Connection from 192.168.1.153 port 51043 Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60_q1.129 Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: no match:
PuTTY_Release_0.60_q1.129
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: Enabling compatibility mode for protocol 2.0 Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: Local version string
SSH-2.0-OpenSSH_4.3
Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: permanently_set_uid:
74/74
Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: list_hostkey_types:
ssh-rsa,ssh-dss
Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: SSH2_MSG_KEXINIT sent Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: SSH2_MSG_KEXINIT received Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: kex: client->server aes256-ctr hmac-sha1 none Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: kex: server->client aes256-ctr hmac-sha1 none Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1:
SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: SSH2_MSG_NEWKEYS sent Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: expecting SSH2_MSG_NEWKEYS Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: SSH2_MSG_NEWKEYS received Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: KEX done Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: userauth-request for user joelc service ssh-connection method none Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: attempt 0 failures 0 Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: PAM: initializing for "joelc"
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: PAM: setting PAM_RHOST to "joelc.local.ca"
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: PAM: setting PAM_TTY to "ssh"
Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: userauth-request for user joelc service ssh-connection method gssapi-with-mic Nov 26 11:53:19 bilbo-rh5 sshd[19330]: debug1: attempt 1 failures 1 Nov 26 11:53:19 bilbo-rh5 sshd[19330]: Postponed gssapi-with-mic for joelc from 192.168.1.153 port 51043 ssh2 Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: Got no client credentials Nov 26 11:53:19 bilbo-rh5 sshd[19329]: Authorized to joelc, krb5 principal joelc at LOCAL.CA (krb5_kuserok) Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: do_pam_account: called Nov 26 11:53:19 bilbo-rh5 sshd[19329]: Accepted gssapi-with-mic for joelc from 192.168.1.153 port 51043 ssh2 Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: monitor_child_preauth:
joelc has been authenticated by privileged process Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: temporarily_use_uid:
20001/600 (e=0/0)
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: No credentials stored Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: restore_uid: 0/0 Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: PAM: establishing credentials Nov 26 11:53:19 bilbo-rh5 sshd[19329]: pam_unix(sshd:session): session opened for user joelc by (uid=0) Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: PAM: reinitializing credentials Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: permanently_set_uid:
20001/600
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: Entering interactive session for SSH2.
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: server_init_dispatch_20 Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1:
server_input_channel_open: ctype session rchan 256 win 16384 max 16384 Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: input_session_request Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: channel 0: new [server-session] Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_new: init Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_new: session 0 Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_open: channel 0 Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_open: session 0:
link with channel 0
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1:
server_input_channel_open: confirm session Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: server_input_channel_req:
channel 0 request x11-req reply 1
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_by_channel:
session 0 channel 0
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1:
session_input_channel_req: session 0 req x11-req Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: channel 1: new [X11 inet listener] Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: channel 2: new [X11 inet listener] Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: server_input_channel_req:
channel 0 request pty-req reply 1
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_by_channel:
session 0 channel 0
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1:
session_input_channel_req: session 0 req pty-req Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: Allocating pty.
Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: session_new: init Nov 26 11:53:19 bilbo-rh5 sshd[19329]: debug1: session_new: session 0 Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_pty_req: session 0 alloc /dev/pts/1 Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: server_input_channel_req:
channel 0 request shell reply 1
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1: session_by_channel:
session 0 channel 0
Nov 26 11:53:19 bilbo-rh5 sshd[19331]: debug1:
session_input_channel_req: session 0 req shell Nov 26 11:53:19 bilbo-rh5 sshd[19332]: debug1: Setting controlling tty using TIOCSCTTY.
The "debug1: Got no client credentials" doesn't look good. Is this a delegation or ticket agent, I'm attempting? Any help would be greatly appreciated!
Thanks! Joel.
________________________________________________
Kerberos mailing list Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
----------------------------------------------------------------------------------------------------------
This message and any attachment, are intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
This message and any attachment, are intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
This message and any attachment, are intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.
----------------------------------------------------------------------------------------------------------
More information about the Kerberos
mailing list