SSO Linux --> AD using GSSAPI

Carter, Joel JoelC at trailerwizards.com
Mon Nov 29 12:03:24 EST 2010


Great, good to know. Definitely prefer using the traditional PuTTY "that just works" over a fork. Just ran 'klist' on my Windows 7 machine as well and was pleased to see something similar to what I've been doing on Linux, putting the puzzle pieces together now!

Thanks again guys,
Joel.

-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Douglas E. Engert
Sent: November-29-10 7:29 AM
To: kerberos at mit.edu
Subject: Re: SSO Linux --> AD using GSSAPI



On 11/26/2010 2:13 PM, SANDERS Miguel wrote:
> Hmm, what value do you have for the RealmFlags in the registry ?
>
> http://technet.microsoft.com/en-us/library/cc736698%28WS.10%29.aspx

Since AD is the KDC, and the client is on Windows, and using SSPI,
it looks like the client is looking at the OK_TO_DELEGATE flag in the
ticket, which is set by the AD KDC in a service ticket based on the
server's userAccountControl TRUSTED_FOR_DELEGATION flag.

See this note:
http://www.mail-archive.com/kerberos@mit.edu/msg12505.html

Two other comments:

(1) The PuTTY SVN versions has SSPI as well as Kerberos for Windows
support. Unfortunately they have not had a release in 3 years,
and the features added in SVN are not listed on the web pages.

  http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
   "The latest development snapshot"


(2) If the PAC is not needed, and the tickets are getting to big,
see http://support.microsoft.com/kb/832572
on how to set the server's userAccountControl NO_AUTH_DATA_REQUIRED
flag.

>
>
> 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.
> ----------------------------------------------------------------------------------------------------------
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos




More information about the Kerberos mailing list