[Rocks-Discuss] Rocks authentication

[Gerry Creager]

For our new cluster, we intend to install Rocks. For our current,
non-Rocks cluster, we've gotten a kerberized LDAP authentication going
with one of our campus' "single" sign-on systems. For a number of
reasons, we'd like to continue the process.

Is this a reasonable process, or will we derail 411 with this approach?

Thanks, gerry
--
Gerry Creager -- gerry....@tamu.edu
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983
Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843

[Tim Carlson]

On Wed, 15 Apr 2009, Gerry Creager wrote:

All of our cluster head nodes authenticate against AD without problem. You
should be able to use pam_krb5 for your setup.

Tim

[Gerry Creager]

Bless you, sir.

[Philip Papadopoulos]

Tim,
Can you tell me how to get started down the path of AD
Authentication

Thanks,
P

--
Sent from my mobile device

Philip Papadopoulos, PhD
University of California, San Diego
858-822-3628 (Ofc)
619-331-2990 (Fax)

[Tim Carlson]

On Wed, 15 Apr 2009, Philip Papadopoulos wrote:

There are really only three things you the Linux side that you need to do
AD authentication.

1) A working /etc/krb5.conf file. This file should list your AD realm and
the servers in that realm. Redhat comes with the standard "example.com"
/etc/krb5.conf. You need to replace example.com with your AD realm and
the correct domain controller names (AD version of a kdc)

To see if you have a working krb5.conf file, you should try to do a

/usr/kerberos/bin/kinit username

and see if you get a Kerberos ticket after entering your AD password.

2) An /etc/pam.d/system-auth file that points to pam_krb5 in the correct
places. Here is what we use. You can delete the pam_afs_session line
because that is specific to our needs. We use it to get AFS tokens from
Kerberos ticket. Obviously you need to fix the "realm=" file for your
particular location.

----------------
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_krb5.so use_first_pass ignore_root realm=PNL.GOV
auth required pam_deny.so

account required pam_unix.so

password required pam_cracklib.so retry=3 type=
password sufficient pam_unix.so nullok use_authtok md5 shadow
password sufficient pam_krb5.so use_authtok ignore_root realm=PNL.GOV
password required pam_deny.so

session required pam_limits.so
session required pam_unix.so
session optional pam_krb5.so ignore_root realm=PNL.GOV
session optional pam_afs_session.so
----------------------

3) Two settings in /etc/ssh/sshd_config that I think need to be set are

UsePAM yes
ChallengeResponseAuthentication no

This of course assumes that you are using usernames that match up with
your AD domain names.

If you have a Rocks 3.x cluster and a "largish" set of AD groups that you
belong to you will run into problems due to the old version of Kerberos
shipped with those systems. Rocks 4.x and 5.x should work just fine.

Tim

-------------------------------------------
Tim Carlson, PhD
Senior Research Scientist
Environmental Molecular Sciences Laboratory

[Steve Jones]

I think it's actually down to two things as the sshd_config settings are default options in later versions. We copy in a new /etc/krb5.conf and /etc/pam.d/system-auth and we're working (with usernames that match). You could go a step further and mount AFS to grep your realm passwd file for UID/GUIDs & use these for account creation.

Here's our system-auth file:

# PAM config for Red Hat
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth [success=ok default=1] /lib/security/$ISA/pam_krb5.so use_first_pass
auth [default=done] /lib/security/$ISA/pam_afs_session.so program=/usr/bin/aklog
auth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_krb5.so
account required /lib/security/$ISA/pam_unix.so

password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password required /lib/security/$ISA/pam_deny.so

session optional /lib/security/$ISA/pam_krb5.so
session required /lib/security/$ISA/pam_afs_session.so program=/usr/bin/aklog
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so

Steve

[Kaufman, Ian]

I've also toyed with even more complication, using LDAP as well.
If your AD is configured to use Services For UNIX, or you play
with the mappings, you can import necessary UIDs and GIDs into
an LDAP query. The combo of LDAP, Kerberos and PAM works pretty
well.

I am using OSX's Open Directory in a similar fashion, configuring
my Solaris 9/10, RHEL 4/5, Ubuntu and FreeBSD 7 clients to pull
auth/auth from Open Directory using LDAP, Kerberos and PAM, and
in some cases, actually pull my automount maps from LDAP as well.

Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering
ikau...@soe.ucsd.edu x49716

[Steve Jones]

> I've also toyed with even more complication, using LDAP as well.
> If your AD is configured to use Services For UNIX, or you play
> with the mappings, you can import necessary UIDs and GIDs into
> an LDAP query. The combo of LDAP, Kerberos and PAM works pretty
> well.
>
> I am using OSX's Open Directory in a similar fashion, configuring
> my Solaris 9/10, RHEL 4/5, Ubuntu and FreeBSD 7 clients to pull
> auth/auth from Open Directory using LDAP, Kerberos and PAM, and
> in some cases, actually pull my automount maps from LDAP as well.

A write-up on the Rocks Wiki would be nice, if you haven't already done one :-)

Steve