[5403] in Release_7.7_team
Notes on using Solaris native login
daemon@ATHENA.MIT.EDU (Robert A Basch)
Thu Jan 26 18:21:10 2006
Message-Id: <200601262320.k0QNKxu4021621@anhedonia.mit.edu>
To: release-team@MIT.EDU
Date: Thu, 26 Jan 2006 18:20:59 -0500
From: Robert A Basch <rbasch@MIT.EDU>
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
Here are the notes I wrote concerning how a stock Solaris system
could be integrated into our environment, i.e. using PAM with Kerberos
authentication, LDAP, etc.
I began by reverting to the stock CDE login on an Athena Solaris
machine, as follows:
* Copy /os/lib/svc/method/console-login to /lib/svc/method (we
replace this in the MIT-ws package).
* Copy /os/usr/bin/login to /usr/bin/login.
* Run "/usr/dt/bin/dtconfig -e" to enable desktop auto-start.
* Reboot for the reconfiguration to take effect.
At this point, the standard Sun CDE login screen will come up.
To set up krb5 authentication, I did the following:
* Install the native krb5 packages, SUNWkrbr and SUNWkrbu.
This includes the pam_krb5 module.
* Configure /etc/krb5/krb5.conf:
- Copy standard athena krb5.conf to /etc/krb5/krb5.conf.
- Remove the "default_keytab_name" setting (presumably the
native krb5 does not like the "ANY:" type).
- Under [libdefaults], add the setting "verify_ap_req_nofail = <boolean>"
where <boolean> is "true" if the machine has a keytab.
* Create /etc/krb5/krb5.keytab, mode 600. If the machine has
an existing keytab, copy it here. If it does not have a keytab,
note that there is an apparent bug, in that authentication
will fail unless /etc/krb5/krb5.keytab exists, so "touch" the
file. Note that my test machine did not have a keytab, so I
did not test that pam_krb5 could successfully verify the
TGT with it.
Note that Sun's pam_krb5 gets v5 tickets only, and does not
get AFS tokens. For the latter, I found the sources for an AFS
PAM module (pam_afs2), and a prerequisite library used to get tokens
(gafstoken), from ftp://achilles.ctd.anl.gov/pub/DEE/. I built and
tested these briefly; while they successfully acquired tokens for the
session, I did not examine them to judge whether they are of
sufficient quality for us to use. (gafstoken actually just creates
a PAG and invokes a configurable external program to get tokens, and
aklog seems to work fine as that program).
Solaris supports passwd lookups via LDAP (but not hesiod). Note
that the LDAP client requires that the shadowAccount object class
be added to the user record for lookups to succeed. I successfully
added this to the schema on a test OpenLDAP server (using a
solaris.schema file found on the net), along with the following change
to the LDIF defining a user entry:
dn: uid=<user>,ou=People,dc=mit,dc=edu
...
objectClass: posixAccount
objectClass: shadowAccount
...
Solaris provides a tool "ldapclient" to configure the LDAP client
service, but it did not work in my testing (perhaps because it changes
nsswitch.conf to do host lookups via ldap?). So to configure the LDAP
client, I did the following:
* Create /var/ldap/ldap_client_file, e.g.:
# comment line
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= ldap.mit.edu
NS_LDAP_SEARCH_BASEDN= dc=mit,dc=edu
NS_LDAP_AUTH= none
NS_LDAP_CACHETTL= 0
(The MIT LDAP server does not support the aforementioned
Solaris-specific schema changes, so I tested against my own
OpenLDAP server, and changed the NS_LDAP_SERVERS and
NS_LDAP_SEARCH_BASEDN settings accordingly).
* Create /var/ldap/ldap_client_cred, with just a comment line.
* Change the passwd and group entries in /etc/nsswitch.conf to
"files ldap". (Note that the MIT LDAP server does not
currently have group records, so the non-primary groups won't
get set).
* Start the LDAP client, and restart the name service cache:
svcadm enable svc:/network/ldap/client
svcadm restart svc:/system/name-service-cache
Finally, to configure dtlogin to use PAM, including the krb5
and afs modules, edit the dtlogin section in /etc/pam.conf,
based on the pam_krb5(5) man page:
# dtlogin service
#dtlogin auth requisite pam_smartcard.so.1
dtlogin auth requisite pam_authtok_get.so.1
dtlogin auth required pam_dhkeys.so.1
dtlogin auth required pam_unix_cred.so.1
dtlogin auth sufficient pam_krb5.so.1
dtlogin auth required pam_unix_auth.so.1
dtlogin session required pam_unix_session.so.1
dtlogin session required /usr/local/lib/pam_afs2.so.1 pgm=/bin/athena/aklog
dtlogin session optional pam_krb5.so.1
Note that the pam_smartcard line comes from the example in the
pam_krb5 man page, but including it caused the login to die, so
I commented it out.
By default, the CDE screensaver locks the screen after a period
of inactivity; to enable krb5 authentication to unlock the screen,
I also added the following entries for the dtsession service
(it might be better to change "other", but I did not try that):
dtsession auth sufficient pam_krb5.so.1
dtsession auth required pam_unix_auth.so.1
After modifying /etc/pam.conf, I needed to reboot, apparently
to restart dtlogin.
With these changes, I was able to login to a standard Athena
account from CDE, with krb5 tickets and tokens. A few issues
quickly became apparent:
1) No v4 tickets (presumably not a long-term issue).
2) Tickets (and tokens) are not destroyed at logout.
3) A few login attempts died because ttsession (Tooltalk message
server) could not start. This might have been caused by
trying to use stale tickets left from a previous session
(see (2)).
4) The CDE desktop is pretty awful. Sun also offers a GNOME 2
desktop, but I did not bother trying to set it up; when I tried
running this on a SunBlade 100 running stock Solaris 10 last year,
the system quickly ran out of memory.
I did not look into how automount might be used to access our
network (AFS) filesystems, except to note that, according to the
documentation, it supports LDAP-based and executable maps.
