Backk to the single sign-on problem with Active Directory and RHEL 5 - SSH

This is a discussion on Backk to the single sign-on problem with Active Directory and RHEL 5 - SSH ; OK, I've got the RHEL 5 box registered in the Active Directory Domain, which we will call "FOO", nad which has the Active Directory name of "FOO.COM" * I've used the RedHat "system-config-authentication" tool register the machine using Winbind, and ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Backk to the single sign-on problem with Active Directory and RHEL 5

  1. Backk to the single sign-on problem with Active Directory and RHEL 5

    OK, I've got the RHEL 5 box registered in the Active Directory Domain,
    which we will call "FOO", nad which has the Active Directory name of
    "FOO.COM"

    * I've used the RedHat "system-config-authentication" tool register
    the machine using Winbind, and temporarily set all Winbind users to
    have the shell /bin/bash.

    * I can login with the username FOO\user, and by tweaking smb.conf can
    log in with the bare username "foo".

    * I've used the "net ads keytab" to set up a local keytab.

    * I've also installed the "Quest" version of Putty, to allow Kerberos
    based logins.

    * I've modified /etc/ssh/sshd_config to allow GSSAPI logins.

    What next? I'm a little confused by the necessary Putty settings, and
    not sure on the server side at a console login how to log in at the
    console, check out the appropriate Kerberos keys, and use them to log
    in password free to similar enabled RHEL servers. What I really wnat
    this for is Subversion access over SSH, to avoid having to do the SSH
    key management fun and games.

  2. Re: Backk to the single sign-on problem with Active Directory and RHEL 5

    >>>>> "NKG" == Nico Kadel-Garcia writes:

    NKG> OK, I've got the RHEL 5 box registered in the Active Directory
    NKG> Domain, which we will call "FOO", nad which has the Active
    NKG> Directory name of "FOO.COM"

    NKG> * I've used the RedHat "system-config-authentication" tool
    NKG> register the machine using Winbind, and temporarily set all
    NKG> Winbind users to have the shell /bin/bash.

    NKG> * I can login with the username FOO\user, and by tweaking
    NKG> smb.conf can log in with the bare username "foo".

    NKG> * I've used the "net ads keytab" to set up a local keytab.

    NKG> * I've also installed the "Quest" version of Putty, to allow
    NKG> Kerberos based logins.

    NKG> * I've modified /etc/ssh/sshd_config to allow GSSAPI logins.

    NKG> What next? I'm a little confused by the necessary Putty settings,
    NKG> and not sure on the server side at a console login how to log in
    NKG> at the console, check out the appropriate Kerberos keys, and use
    NKG> them to log in password free to similar enabled RHEL
    NKG> servers. What I really wnat this for is Subversion access over
    NKG> SSH, to avoid having to do the SSH key management fun and games.

    Hi Nico,

    There are two places where SSH may be kerberized: server and client
    authentication. Vanilla OpenSSH supports only the latter. There is a
    patch for adding the former:

    http://www.sxw.org.uk/computing/patches/openssh.html

    Some distros add this support to their OpenSSH builds, e.g. Debian. I
    don't know about RHEL.

    On the server side, do this to see that the necessary host keys are in
    place:

    sequoia:~# klist -ek /etc/krb5.keytab
    Keytab name: FILE:/etc/krb5.keytab
    KVNO Principal
    ---- --------------------------------------------------------------------------
    4 host/sequoia.oankali.net@OANKALI.NET (Triple DES cbc mode with HMAC/sha1)
    4 host/sequoia.oankali.net@OANKALI.NET (DES cbc mode with CRC-32)
    4 host/sequoia.oankali.net@OANKALI.NET (AES-256 CTS mode with 96-bit SHA-1 HMAC)
    4 host/sequoia.oankali.net@OANKALI.NET (ArcFour with HMAC/md5)

    sshd expects its service principal to be the standard "host" principal,
    "host/@REALM" (this is not configurable); this shows four keys
    present for that principal, of various types. In your case, there will
    probably be just one DES key.

    In Quest PuTTY, there are a few options bearing on Kerberos:

    * Connection / SSH / Kex: "Enable GSSAPI algorithms"

    This turns on kerberized key exchange (server authentication).

    * Connection / SSH / GSSAPI

    - Attempt GSSAPI auth (SSH-2)

    o try kerberized userauth

    - Server determines username from credentials

    o not sure what this does

    - Delegate credentials

    o Forward TGT across connection. In your setup, this will only work
    if you've marked the server as safe for delegation in AD.

    - Trust DNS

    o Use the DNS to canonicalize the hostname when constructing the
    service principal name. This is convenient since you can then use
    short hostnames in PuTTY, but it is less secure.

    - Service principal name (Kerberos)

    o Specify the server principal name manually, in case automatic
    determination is not working for some reason.

    For debugging, I find it easier to use plink -v rather than the PuTTY GUI.

    Another useful tool is klist.exe, a Microsoft utility that allows you to
    view the SSPI ticket cache, and delete tickets.

    --
    Richard Silverman
    res@qoxp.net


  3. Re: Backk to the single sign-on problem with Active Directory andRHEL 5

    On Feb 15, 6:34*pm, "Richard E. Silverman" wrote:

    [ previous post excluded ]

    > Hi Nico,
    >
    > There are two places where SSH may be kerberized: server and client
    > authentication. *Vanilla OpenSSH supports only the latter. *There is a
    > patch for adding the former:
    >
    > http://www.sxw.org.uk/computing/patches/openssh.html
    >
    > Some distros add this support to their OpenSSH builds, e.g. Debian. *I
    > don't know about RHEL.


    It's clearly not in RHEL 5's SRPM's.

    > On the server side, do this to see that the necessary host keys are in
    > place:
    >
    > sequoia:~# klist -ek /etc/krb5.keytab
    > Keytab name: FILE:/etc/krb5.keytab
    > KVNO Principal
    > ---- --------------------------------------------------------------------------
    > * *4 host/sequoia.oankali....@OANKALI.NET (Triple DES cbc mode with HMAC/sha1)
    > * *4 host/sequoia.oankali....@OANKALI.NET (DES cbc mode with CRC-32)
    > * *4 host/sequoia.oankali....@OANKALI.NET (AES-256 CTS mode with 96-bit SHA-1 HMAC)
    > * *4 host/sequoia.oankali....@OANKALI.NET (ArcFour with HMAC/md5)


    Right. This looks good. Should I be using the Winbind authentication
    and user management for this? Or just the Kerberos user
    authentication, as managed by the RHEL tools "authconfig-tui"? The /
    etc/krb5.conf from RHEL has a bunch of settings for "EXAMPLE.COM",
    even after running the configuration tool. I think those can and
    should be removed.

    > sshd expects its service principal to be the standard "host" principal,
    > "host/@REALM" (this is not configurable); this shows four keys
    > present for that principal, of various types. *In your case, there will
    > probably be just one DES key.




    > In Quest PuTTY, there are a few options bearing on Kerberos:
    >
    > * Connection / SSH / Kex: "Enable GSSAPI algorithms"
    >
    > * This turns on kerberized key exchange (server authentication).
    >
    > * Connection / SSH / GSSAPI
    >
    > * - Attempt GSSAPI auth (SSH-2)
    >
    > * * o try kerberized userauth
    >
    > * - Server determines username from credentials
    >
    > * * o not sure what this does


    I think this pulls your credentials from your Windows domain login,
    which is quite commonly available for an Active Directory registered
    Windows host. This is actually consistent with what I want. There's
    some potential for conflict there, because Windows seems to list the
    keys as "DOMAIN\username", and your smb.conf needs to be set correctly
    to allow you to use the more sensible "username" or "DOMAIN_username"
    formats.

    > * - Delegate credentials
    >
    > * * o Forward TGT across connection. *In your setup, this will only work
    > * * * if you've marked the server as safe for delegation in AD.


    Cool. In the current environment, I'd be happy to forward my
    authentication through the connection, to ease other Kerberized
    services from my active logins on the Linux box.


    > * - Trust DNS
    >
    > * * o Use the DNS to canonicalize the hostname when constructing the
    > * * * service principal name. *This is convenient since you can then use
    > * * * short hostnames in PuTTY, but it is less secure.
    >
    > * - Service principal name (Kerberos)
    >
    > * * o Specify the server principal name manually, in case automatic
    > * * * determination is not working for some reason.
    >
    > For debugging, I find it easier to use plink -v rather than the PuTTY GUI.
    >
    > Another useful tool is klist.exe, a Microsoft utility that allows you to
    > view the SSPI ticket cache, and delete tickets.


    Do you know of where a working version is for Windows XP? I'm seeing
    lots of references to Windows 2003 versions of the tool.

  4. Re: Backk to the single sign-on problem with Active Directory and RHEL 5


    > On Feb 15, 6:34*pm, "Richard E. Silverman" wrote:
    > [ previous post excluded ]
    >
    > > Hi Nico,
    > >
    > > There are two places where SSH may be kerberized: server and client
    > > authentication. *Vanilla OpenSSH supports only the latter. *There is a
    > > patch for adding the former:
    > >
    > > http://www.sxw.org.uk/computing/patches/openssh.html
    > >
    > > Some distros add this support to their OpenSSH builds, e.g. Debian. *I
    > > don't know about RHEL.

    >
    > It's clearly not in RHEL 5's SRPM's.
    >
    > > On the server side, do this to see that the necessary host keys are in
    > > place:
    > >
    > > sequoia:~# klist -ek /etc/krb5.keytab
    > > Keytab name: FILE:/etc/krb5.keytab
    > > KVNO Principal
    > > ---- --------------------------------------------------------------------------
    > > * *4 host/sequoia.oankali....@OANKALI.NET (Triple DES cbc mode with HMAC/sha1)
    > > * *4 host/sequoia.oankali....@OANKALI.NET (DES cbc mode with CRC-32)
    > > * *4 host/sequoia.oankali....@OANKALI.NET (AES-256 CTS mode with 96-bit SHA-1 HMAC)
    > > * *4 host/sequoia.oankali....@OANKALI.NET (ArcFour with HMAC/md5)

    >
    > Right. This looks good. Should I be using the Winbind authentication
    > and user management for this? Or just the Kerberos user
    > authentication, as managed by the RHEL tools "authconfig-tui"? The /


    I'm not familiar with those; when joining a Unix machine to an AD realm,
    I've always just used ktpass.exe to extract a keytab.

    > etc/krb5.conf from RHEL has a bunch of settings for "EXAMPLE.COM",
    > even after running the configuration tool. I think those can and
    > should be removed.


    Sure.

    > > sshd expects its service principal to be the standard "host" principal,
    > > "host/@REALM" (this is not configurable); this shows four keys
    > > present for that principal, of various types. *In your case, there will
    > > probably be just one DES key.

    >
    >
    >
    > > In Quest PuTTY, there are a few options bearing on Kerberos:
    > >
    > > * Connection / SSH / Kex: "Enable GSSAPI algorithms"
    > >
    > > * This turns on kerberized key exchange (server authentication).
    > >
    > > * Connection / SSH / GSSAPI
    > >
    > > * - Attempt GSSAPI auth (SSH-2)
    > >
    > > * * o try kerberized userauth
    > >
    > > * - Server determines username from credentials
    > >
    > > * * o not sure what this does

    >
    > I think this pulls your credentials from your Windows domain login,
    > which is quite commonly available for an Active Directory registered
    > Windows host. This is actually consistent with what I want. There's
    > some potential for conflict there, because Windows seems to list the
    > keys as "DOMAIN\username", and your smb.conf needs to be set correctly
    > to allow you to use the more sensible "username" or "DOMAIN_username"
    > formats.
    >
    > > * - Delegate credentials
    > >
    > > * * o Forward TGT across connection. *In your setup, this will only work
    > > * * * if you've marked the server as safe for delegation in AD.

    >
    > Cool. In the current environment, I'd be happy to forward my
    > authentication through the connection, to ease other Kerberized
    > services from my active logins on the Linux box.
    >
    >
    > > * - Trust DNS
    > >
    > > * * o Use the DNS to canonicalize the hostname when constructing the
    > > * * * service principal name. *This is convenient since you can then use
    > > * * * short hostnames in PuTTY, but it is less secure.
    > >
    > > * - Service principal name (Kerberos)
    > >
    > > * * o Specify the server principal name manually, in case automatic
    > > * * * determination is not working for some reason.
    > >
    > > For debugging, I find it easier to use plink -v rather than the PuTTY GUI.
    > >
    > > Another useful tool is klist.exe, a Microsoft utility that allows you to

    > view the SSPI ticket cache, and delete tickets.
    >
    > Do you know of where a working version is for Windows XP? I'm seeing
    > lots of references to Windows 2003 versions of the tool.


    --
    Richard Silverman
    res@qoxp.net


+ Reply to Thread