I've got Winbind working, now I want single-sign-on - SSH

This is a discussion on I've got Winbind working, now I want single-sign-on - SSH ; I've gotten Winbind working for RHEL 5: many of the published notes tend to leave out little details, like the need to enter your username as DOMAIN\username unless you've hand-edited smb.conf to support '_' as your separator, or to use ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: I've got Winbind working, now I want single-sign-on

  1. I've got Winbind working, now I want single-sign-on

    I've gotten Winbind working for RHEL 5: many of the published notes
    tend to leave out little details, like the need to enter your username
    as DOMAIN\username unless you've hand-edited smb.conf to support '_'
    as your separator, or to use 'winbind use default domain' and avoid
    the idmap_nss confusion.

    But I'd really like to get it working so that the Windows users do
    *not* have to manually type in passwords. Let me explain that I'm
    dealing with an SSH accessed terminal interface, which works fine in
    Putty, but for which I wish to simplify the user's access to it once
    they've authenticated to their Windows guest box, since it's providing
    Winbind based password handling anyway.

    Has anyone done this? Or are all the "single sign-on" references I've
    found simply referring to single password, not to such an automatic
    authentication technique?

  2. Re: I've got Winbind working, now I want single-sign-on

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

    NKG> I've gotten Winbind working for RHEL 5: many of the published
    NKG> notes tend to leave out little details, like the need to enter
    NKG> your username as DOMAIN\username unless you've hand-edited
    NKG> smb.conf to support '_' as your separator, or to use 'winbind use
    NKG> default domain' and avoid the idmap_nss confusion.

    NKG> But I'd really like to get it working so that the Windows users
    NKG> do *not* have to manually type in passwords. Let me explain that
    NKG> I'm dealing with an SSH accessed terminal interface, which works
    NKG> fine in Putty, but for which I wish to simplify the user's access
    NKG> to it once they've authenticated to their Windows guest box,
    NKG> since it's providing Winbind based password handling anyway.

    NKG> Has anyone done this? Or are all the "single sign-on" references
    NKG> I've found simply referring to single password, not to such an
    NKG> automatic authentication technique?

    Hi Nico,

    If the Windows boxes are part of a domain, then your users have Kerberos
    credentials once they log in. You can use them with kerberized SSH to get
    single-signon. There is a kerberized version of PuTTY here:

    http://rc.quest.com/topics/putty/

    The SSH server needs to support at least gssapi user authentication --
    Quest PuTTY supports kerberized key exchange as well, but that's not
    strictly necessary for single-signon.

    You can have the Unix machine be part of the domain (meaning specifically
    that it needs a host principal in AD and a matching keytab entry on the
    host). You can do this by creating a "user" in AD to represent the host,
    and using the ktpass.exe utility to attach the Kerberos principal to the
    account and create a keytab. Alternatively, you can have a separate
    Kerberos realm for the Unix hosts and establish cross-realm trust with
    AD. There are some extra complications going with that route, though.

    --
    Richard Silverman
    res@qoxp.net


  3. Re: I've got Winbind working, now I want single-sign-on

    On 21 Dec, 02:59, "Richard E. Silverman" wrote:
    > >>>>> "NKG" == Nico Kadel-Garcia writes:

    >
    > * * NKG> I've gotten Winbind working for RHEL 5: many of the published
    > * * NKG> notes tend to leave out little details, like the need to enter
    > * * NKG> your username as DOMAIN\username unless you've hand-edited
    > * * NKG> smb.conf to support '_' as your separator, or to use 'winbinduse
    > * * NKG> default domain' and avoid the idmap_nss confusion.
    >
    > * * NKG> But I'd really like to get it working so that the Windows users
    > * * NKG> do *not* have to manually type in passwords. Let me explain that
    > * * NKG> I'm dealing with an SSH accessed terminal interface, which works
    > * * NKG> fine in Putty, but for which I wish to simplify the user's access
    > * * NKG> to it once they've authenticated to their Windows guest box,
    > * * NKG> since it's providing Winbind based password handling anyway.
    >
    > * * NKG> Has anyone done this? Or are all the "single sign-on" references
    > * * NKG> I've found simply referring to single password, not to such an
    > * * NKG> automatic authentication technique?
    >
    > Hi Nico,


    Hi, Richard! It's always nice to see your messages.

    I'm in the UK right now, working ona migration of SCO boxes to Linux,
    and would really like to show off how to do things in a secure
    fashion. If this works well, it can also help address the Subversion
    SSH+svnserve issues and people's tendencies to leave password free SSH
    keys lying around on their laptops and unsecured boxes. So I've got my
    fingers crossed that this will work well. I've never gotten the
    traction in previous environments to get integration help with the
    Active Directory administrators: now I do. Life is good.

    > If the Windows boxes are part of a domain, then your users have Kerberos
    > credentials once they log in. *You can use them with kerberized SSH to get
    > single-signon. *There is a kerberized version of PuTTY here:
    >
    > http://rc.quest.com/topics/putty/


    The "Active Directory domain users have Kerberos credentials" part, I
    already understood, thanks.

    I hadn't realized that Siman Tatham's version of Putty was not
    Kerberized: I've loved and recommended the standard Putty tool for
    years, and only wish the Linux terminals were anywhere near so
    wonderful.

    I'll test this Putty version out today and see if I have to do
    anything else. If not, woo-hoo! I'll publish notes. There are lots of
    guidelines to how to set up RHEL for Winbind, but they seem not to be
    complete.

    > The SSH server needs to support at least gssapi user authentication --
    > Quest PuTTY supports kerberized key exchange as well, but that's not
    > strictly necessary for single-signon.
    >
    > You can have the Unix machine be part of the domain (meaning specifically
    > that it needs a host principal in AD and a matching keytab entry on the
    > host). *You can do this by creating a "user" in AD to represent the host,
    > and using the ktpass.exe utility to attach the Kerberos principal to the
    > account and create a keytab. *Alternatively, you can have a separate
    > Kerberos realm for the Unix hosts and establish cross-realm trust with
    > AD. *There are some extra complications going with that route, though.


    I've gotten RHEL 5 boxes registered to the domain with Winbind, using
    RedHat's very friendly "authconfig-gui" or "authconfig-tui" tool. RHEL
    5 changed the system-config-authentication tool to not call up any gui
    if you run it directly, only to present you with a list of command
    line arguments. I recommend authconfig-gui: the error messages if you
    fail to join a domain flash by far, far too quickly on the authconfig-
    tui, so you never know what failed.

    These machines are using Winbind for both authentication and account
    configurations, so the RHEL boxes are now listed among the "Hosts" in
    the Active Directgory configuration tools. I'm able to log in using
    the Windows account names and passwords this way for users not in the
    RHEL box's /etc/passwd files, so I'm good there.

    It leads to some oddness: the "groups" of Windows users can have
    spaces in the names, so the default group of "Domain Users" becomes
    "domain users" and makes for confusing output. I may have to tweak
    some old scripts to use "ls -n" to deal with this.

    A separate Kerberos realm sounds like a great deal of pain for the
    relatively small environment I'm in: I really don't want to go there.
    Maintaining another Kerberos server when there is already an Active
    Directory server running for other reasons seems.... like putting
    another door on the barn, and then trying to lock *that*. If I needed
    to actually have a separate barn for the Linux environment, I'd
    consider it.

    And oh, yes! Andrew Tridgell and Jeremy Allison in the Samba world
    just announced a deal that provides Samba developers with access to
    Microsoft's actual protocols for Active Directory, so we can expect to
    see better integration for Samba. And potentially related SSH
    authentication questions, as I'm encountering.

  4. Re: I've got Winbind working, now I want single-sign-on

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

    NKG> On 21 Dec, 02:59, "Richard E. Silverman" wrote:
    >> >>>>> "NKG" == Nico Kadel-Garcia writes:

    >>
    >> * * NKG> I've gotten Winbind working for RHEL 5: many of the
    >> published * * NKG> notes tend to leave out little details, like the
    >> need to enter * * NKG> your username as DOMAIN\username unless
    >> you've hand-edited * * NKG> smb.conf to support '_' as your
    >> separator, or to use 'winbind use * * NKG> default domain' and
    >> avoid the idmap_nss confusion.
    >>
    >> * * NKG> But I'd really like to get it working so that the Windows
    >> users * * NKG> do *not* have to manually type in passwords. Let me
    >> explain that * * NKG> I'm dealing with an SSH accessed terminal
    >> interface, which works * * NKG> fine in Putty, but for which I wish
    >> to simplify the user's access * * NKG> to it once they've
    >> authenticated to their Windows guest box, * * NKG> since it's
    >> providing Winbind based password handling anyway.
    >>
    >> * * NKG> Has anyone done this? Or are all the "single sign-on"
    >> references * * NKG> I've found simply referring to single password,
    >> not to such an * * NKG> automatic authentication technique?
    >>
    >> Hi Nico,


    NKG> Hi, Richard! It's always nice to see your messages.

    NKG> I'm in the UK right now, working ona migration of SCO boxes to
    NKG> Linux, and would really like to show off how to do things in a
    NKG> secure fashion. If this works well, it can also help address the
    NKG> Subversion SSH+svnserve issues and people's tendencies to leave
    NKG> password free SSH keys lying around on their laptops and
    NKG> unsecured boxes. So I've got my fingers crossed that this will
    NKG> work well. I've never gotten the traction in previous
    NKG> environments to get integration help with the Active Directory
    NKG> administrators: now I do. Life is good.

    >> If the Windows boxes are part of a domain, then your users have
    >> Kerberos credentials once they log in. *You can use them with
    >> kerberized SSH to get single-signon. *There is a kerberized version
    >> of PuTTY here:
    >>
    >> http://rc.quest.com/topics/putty/


    NKG> The "Active Directory domain users have Kerberos credentials"
    NKG> part, I already understood, thanks.

    NKG> I hadn't realized that Siman Tatham's version of Putty was not
    NKG> Kerberized: I've loved and recommended the standard Putty tool
    NKG> for years, and only wish the Linux terminals were anywhere near
    NKG> so wonderful.

    NKG> I'll test this Putty version out today and see if I have to do
    NKG> anything else. If not, woo-hoo! I'll publish notes. There are
    NKG> lots of guidelines to how to set up RHEL for Winbind, but they
    NKG> seem not to be complete.

    >> The SSH server needs to support at least gssapi user authentication
    >> -- Quest PuTTY supports kerberized key exchange as well, but that's
    >> not strictly necessary for single-signon.
    >>
    >> You can have the Unix machine be part of the domain (meaning
    >> specifically that it needs a host principal in AD and a matching
    >> keytab entry on the host). *You can do this by creating a "user" in
    >> AD to represent the host, and using the ktpass.exe utility to
    >> attach the Kerberos principal to the account and create a
    >> keytab. *Alternatively, you can have a separate Kerberos realm for
    >> the Unix hosts and establish cross-realm trust with AD. *There are
    >> some extra complications going with that route, though.


    NKG> I've gotten RHEL 5 boxes registered to the domain with Winbind,
    NKG> using RedHat's very friendly "authconfig-gui" or "authconfig-tui"
    NKG> tool. RHEL 5 changed the system-config-authentication tool to not
    NKG> call up any gui if you run it directly, only to present you with
    NKG> a list of command line arguments. I recommend authconfig-gui:
    NKG> the error messages if you fail to join a domain flash by far, far
    NKG> too quickly on the authconfig- tui, so you never know what
    NKG> failed.

    NKG> These machines are using Winbind for both authentication and
    NKG> account configurations, so the RHEL boxes are now listed among
    NKG> the "Hosts" in the Active Directgory configuration tools. I'm
    NKG> able to log in using the Windows account names and passwords this
    NKG> way for users not in the RHEL box's /etc/passwd files, so I'm
    NKG> good there.

    I haven't used Winbind, so I don't know the details; however, for sshd
    to work with Kerberos, you need the host principal key (host/fqnd@REALM)
    in the system keytab (usually /etc/krb5.keytab).

    NKG> It leads to some oddness: the "groups" of Windows users can have
    NKG> spaces in the names, so the default group of "Domain Users"
    NKG> becomes "domain users" and makes for confusing output. I may have
    NKG> to tweak some old scripts to use "ls -n" to deal with this.

    NKG> A separate Kerberos realm sounds like a great deal of pain for
    NKG> the relatively small environment I'm in: I really don't want to
    NKG> go there. Maintaining another Kerberos server when there is
    NKG> already an Active Directory server running for other reasons
    NKG> seems.... like putting another door on the barn, and then trying
    NKG> to lock *that*. If I needed to actually have a separate barn for
    NKG> the Linux environment, I'd consider it.

    NKG> And oh, yes! Andrew Tridgell and Jeremy Allison in the Samba
    NKG> world just announced a deal that provides Samba developers with
    NKG> access to Microsoft's actual protocols for Active Directory, so
    NKG> we can expect to see better integration for Samba. And
    NKG> potentially related SSH authentication questions, as I'm
    NKG> encountering.

    --
    Richard Silverman
    res@qoxp.net


  5. Re: I've got Winbind working, now I want single-sign-on

    On 21 Dec, 17:10, "Richard E. Silverman" wrote:

    > I haven't used Winbind, so I don't know the details; however, for sshd
    > to work with Kerberos, you need the host principal key (host/fqnd@REALM)
    > in the system keytab (usually /etc/krb5.keytab).


    Apparently so, although RedHat does a few fascinating odd bits such as
    locating the keytab that take some analysis or reading the right docs
    to figure out. /etc/krb.conf and the PAM modules get set up gracefully
    by usiing the authconfig-tui or authconfig-gui tools and following
    their clear directions. I'm still getting NTP straightened out, so
    failures are going to be a bit difficult for me to diagnose fully
    until I can get a few moments for the AD administrators to actually
    reboot that Primary Domain Controller, which needed to be held back
    until after the holiday.

    I apparently also need to enable Kerberos in the /etc/ssh/sshd_config,
    which I've done in my test setups.

  6. Re: I've got Winbind working, now I want single-sign-on

    Nico Kadel-Garcia writes:

    > Has anyone done this? Or are all the "single sign-on" references
    > I've found simply referring to single password, not to such an
    > automatic authentication technique?


    Yep. From memory:

    * Use winbind to make Unix box member of AD domain.

    * net ads keytab on the Unix box to generate a keytab from the Unix
    box's computer account in AD.

    * GSSAPIAuthentication yes in /etc/ssh/sshd_config

    * A kerberized PuTTY such as Quest. I'm working on kerberizing
    official PuTTY now I have the need, but other things are currently
    taking precedence.

    Owen

+ Reply to Thread