Re: New option sugestion for Users and Groups

[Jamie C. <jca...@we...>]

lis...@ne... wrote:

> What I'd really like to see is the ability to define which options are
> available to which users in U & G.  All of the changes I made to the U & G
> module removed (or hid) many options.  Let me put this in context.  I
> don't want a customer service rep to be able to assign a uid, shell,
> group, or passwd expiration option.  I don't want them to be able to edit
> an encrypted passwd either.  To do this I had to jack with some HTML
> output.  I'd like this to be configurable though so that I don't have to
> make a 2nd module for different types of webmin users.  I liked to make
> better alterations to the module but I don't think my abilities are up to
> par for the task.


A lot of those can already be set on a per-webmin-user basis. If you go
into the Webmin Users module and click on Users and Groups next to a username,
you will see options for controlling which shells are available and so on.
Tell me if there are any more you would like added though ..

 
> One a related note, I can think of a few other features that would be very
> useful to the U & G module.
> 
> Auto-generated passwds (random with mixed case or at least fit my
> criteria).  Since U & G doesn't use passwd to check a submitted passwd
> prior to sticking it in the shadow file, it doesn't have the ability to
> make sure the passwd is resonably secure.  This would be a wonderful
> addition.  Way back when I used to do tech support, we allowed users to
> pick their passwd.  I saw people spend 30 minutes in our office trying to
> think of one they liked that fit our admins criteria.  It tried on the
> patience of the helpdesk staff, frequently embarassed and frustrated the
> user, and wasted a lot of our time which could be spent helping someone
> else (slowing down everyone else's response time and hacking them off to
> no ends).  Finally our admins came up with a secure way to assign userids
> and passwds online to registered students.  The web page was plastered
> across every piece of IT document that was given to the students.
> Professors even gave it out in class on the first day.  That cut our
> support time/costs considerably giving us the resources to help the people
> that really needed helped.  The web form didn't screw around either.  It
> assigned you your userid and a randomly generated passwd.  You could
> change your passwd on your own time via another secure form later.  Having
> the auto-assign ability would be excellent.
> 
> Common passwd checks.  I'd like to see the new passwd checked against the
> system dictionary file as well as checked against an admin-defined
> miniumum length and use of characters (ie, looking for the use of letters
> AND numbers).  This would go along ways to strength passwd security.
> 
> Userid checks.  I'd like to see some basic sanity checking for new
> userids.  It should make sure that all numeric userids aren't permitted.
> It should also check for userids that begin with numerals.  It should also
> allow the admin to define a maximum length for userids.  Making certain
> that *only* alphanumeric characters are used would also be a good thing
> (no more periods, dashes, and underscores--while they aren't always a bad
> thing, they are annoying).


All those features have already been implemented, and will be in the next
release of webmin :)  Under Module Config will be options for setting the
minimum password length, a regexp to check against, and an option to check for
dictionary words. There is already an option in there to generate a random
password for a user by default..

You can get a pre-release with these features from http://www.webmin.com/devel/


> The last thing I can think of is a uid check.  I imagine that U & G makes
> sure that I don't use uids below the minimum I'm allowed to edit (so a
> userid isn't created with a daemon's (or root's) uid).  What I've had
> problems with in the past is a CSR creating one user, then backing the
> browser up a page, changing the userid, and resubmitting the form.  The
> uid is assigned twice.  This usually happens when a secondary userid is
> created for a new customer.  If webmin doublechecked the uid, a duplicate
> uid entry wouldn't be made.  An alternative would be to set (or check for)
> a cookie to make sure that the form wasn't submitted more than once.


UID clash checking and range checking is already available - just go into
Webmin Users, and click on Users and Groups next to a username.

  - Jamie