password quality script aka --with-cracklib replacement

[Pierre Belanger]

Hi,

Here's what I've come up for the "password quality script",
cracklib "replacement" after exchanging a few email and reading
what came up on the mailing list. Your comments are again very
welcome -- I've come up with this but if it's all wrong fell
free to "blast me" ;-) I had good fun doing it and if something
needs to be change, I'll be happy to change it! The code, the
documentation and an example script are ready. I even stepped
out of the code a few days came back and made a few more
changes.

1) cracklib

The idea to have cracklib (v2.7) directly linked in smbd was
abandon because it was adding support *only* for cracklib
and a few changes were required in cracklib's code. Cracklib
is under "artistic" license which is not compatible with GNU,
etc.

2) password quality script

What is it? I have my own comments at the end ...

 From the documentation I wrote (even if I'm French I think it's not
that bad!?!?!?):

           Full path to the script that  will  be  called  when  a
           request for change password is received. It will be run
           by smbd as non-ROOT.

           The script is responsible to accept or refuse  the  new
           password  based on its own rules. As an example, it can
           be a script refusing a weak password based  on  a  dic-
           tionary word.

           Samba back end communicates with the  password  quality
           program  by  writing data to its STDIN and reading data
           from its STDOUT.  Samba  writes  a  block  of  data  in
           "Field:value\n"  terminated by a ".\n" at the beginning
           of a new line.

           1) smbd to ---> Password quality script "STDIN"

                     Version:smbd-version-string\n
                     Username:username\n
                     Fullname:fullname\n
                     Password:new-password\n
                     .\n



           The above  fields  are  filled  with  their  respective
           value.   Once  smbd  writes  on the last line ".\n", it
           waits from the script its response and exit status.

           IMPORTANT NOTES: The "smbd-version-string" may  contain
           alpha  characters,  for  example:  2.2.8pre1. The "new-
           password" may have a leading or trailing  space  --  be
           carefull when parsing the data.

           2) Password quality script "STDOUT" to ---> smbd

                     NTStatus:ntstatus-string\n
                     Result:result-string\n
                     .\n



           The "ntstatus-string" value  must  used  one  the  pre-
           defined NTSTATUS (nterr.h) values. In this context:

           NT_STATUS_OK # New password accepted

           NT_STATUS_ACCESS_DENIED # Error occured in the script

           NT_STATUS_PASSWORD_RESTRICTION # Too short,  weak, etc.

           The "result-string" value is used to  provide  informa-
           tion (debug info) to smbd. For examples:

                     NTStatus:NT_STATUS_PASSWORD_RESTRICTION\n
                     Result:Password is based on dictionary word\n

                     or

                     NTStatus:NT_STATUS_OK\n
                     Result:New password is accepted\n

           smbd will always return an error to the client and does
           not  change  the  current  password unless the NTStatus
           value is equal to "NT_STATUS_OK" and the exit status of
           the script equal to 0.

           Default: password quality script = <empty string>

           Example:      password      quality      script       =
           /usr/local/samba/sbin/password-quality.pl



Do you wonder why sending the "smbd-version-string"? Perhaps
in the future a new NTSTATUS will be added. The only way for the
external program to know if it can use the new value is by
knowing the version of Samba! There are other possible examples.

[Q] What do we do with the fullname? We don't care? What if it's not
available ('\0')? Do we write to the external program an empty string
like this  ->Fullname:\n<-  or we just don't send the fullname field
to the external program or perhaps something like "Fullname:Unknown\n"?
I think -- either we always send something (Unknown when it's empty)
or we just don't send it. I think it's less confusing for everyone
is we write in the documentation if fullname is not known, we write
"Unknown" (or empty or NULL!).

Let me know what you think and/or other ideas.

Thank you again,
Pierre B.