Why Samba didn't use pam to hook into cracklib

[Andrew Bartlett]

Perhaps I should explain a little about the history of Samba cracklib
patches, because it seems rather relevant to the current discussion on
heimdal-discuss.  The history here may be of interest to samba-
technical, so I've CC'ed it there.

Soon after I deployed a new login service at Hawker College, I found
that students were quite happy to choose 'dog' and 'cat' at their
passwords.  I snapped - if students were going to be allowed to choose
their own passwords (and I didn't want to make them keep computer-
generated ones), then I would need to enforce cracklib.

Later, the way our system worked changed, and it took over the NT domain
logon, and I had to make Samba become the first line of defense against
silly passwords.

I added a patch to our local Samba installation, that crudely called
cracklib on a user password change (not an admin password set).  This
was fairly easy - cracklib is not a difficult interface, and I just
manually added -lcrack to the LDFLAGS.

I wanted to make cracklib part of normal Samba life - I think it is
vital to have this kind of support in any 'enterprise' product, and if
it was useful to me, it would be useful to others.  I worked on
configure checks, and got the whole thing 'working'.  However, we hit
the nasty behaviour of the cracklib library - if the dictionary file is
absent, the *library* calls exit(1).  

This misbehaviour (we could not make our admins debug that kind of
behaviour) led to the patches removal, and later, Simo Sorce added
another patch - this time, we called an external helper, as a fork()ed
child, and he created examples/auth/crackcheck.c from the remains of my
previous patch.  This is called when 'check password script' is set.

This ensures that if it calls exit(1), we just deny the password change,
and admins can specify a password policy that they feel comfortable with
(perhaps also performing other checks).


Hmm, but I haven't explained 'why not PAM'.  We looked at PAM as an
interface to existing, working cracklib code shipped on many of our
target OS platforms, but it is not a very good fit at all.  In the PAM
case, Samba wants to be both the client application, and the target
library to which the password may be set.  This is complex, both because
the target library is a configuration issue outside the control of
Samba, and because we would then have to ship the 'actually set the
password' part as a PAM module, not as part of the main Samba code.

We also hit against the issue of PAM as 'no previous password'.  If we
are setting a password without the previous plaintext, we have to be
root (otherwise the previous password is prompted for), this causes
pam_cracklib to go into 'advise, but not enforcement' mode.  A poor
password will be allowed, and it can only be detected by the PAM comment
returned for display to the user.

All this made us just use the normal cracklib library, in a child
process.


Finally, I should note my views on where this password quality check
should be peformed.  In an ideal world, I would perform this password
quality check in the LDAP server too which Samba and Heimdal both read
their password databases from.  The password server should obtain a
plaintext password (via for example the OpenLDAP password setup ExOP),
and it should return a status regarding the quality of the password, if
it were too poor.  Preferably this would include a text error string,
for communication to the client if supported by the relevant protocols.
(And then a good password would be set in all encryption types and Samba
hashes, into the LDAP DB).

However, in a world where we don't yet do this, (Samba doesn't pass back
specific errors from ldap very well, heimdal doesn't use the password
set API, and we should cover the hdb-db), I would suggest cracklib be
integrated into the password check API of heimdal as a child process, so
that the two ways that a password may be set in my current directory
setup are covered with some kind of check.  On my unix workstations,
I'll probably also enforce local pam_cracklib, as this can get previous
passwords, as well as return decent error strings.

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050410/891f984d/attachment.bin