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.sand...@arcelormittal.com www.arcelormittal.com/gent >P Please consider the environment before printing this e-mail -----Oorspronkelijk bericht----- Van: Carter, Joel [mailto:jo...@trailerwizards.com] Verzonden: vrijdag 26 november 2010 21:11 Aan: SANDERS Miguel; kerberos@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: jo...@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: jo...@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.sand...@arcelormittal.com] Sent: November-26-10 12:05 PM To: Carter, Joel; kerberos@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.sand...@arcelormittal.com www.arcelormittal.com/gent >P Please consider the environment before printing this e-mail -----Oorspronkelijk bericht----- Van: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] Namens Carter, Joel Verzonden: vrijdag 26 november 2010 20:59 Aan: kerberos@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 jo...@bilbo-rh5.local.ca's password: Last login: Fri Nov 26 11:34:13 2010 from joelc.local.ca [jo...@bilbo-rh5 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_20001_SwXGUD Default principal: jo...@local.ca Valid starting Expires Service principal 11/26/10 11:44:43 11/26/10 21:43:47 krbtgt/local...@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...@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 [jo...@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 jo...@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@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. ---------------------------------------------------------------------------------------------------------- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
