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
This is a digitally signed message part