Tru64-UNIX-Managers Archive (1998) - SUMMARY: old /etc/passwd , old machine --> new machine ,enhanced securit

Well, this was the answer I was waiting for:

On Fri, 30 Jan 1998, Tim Mooney wrote:

> On Wed, 21 Jan 1998, Alberto Dainotti wrote:
> 
> >I have 3000+ users on a server running Digital Unix 3.2
> >Most of the users connect using ppp on a dial-up line.
> >The system runs under "base" security.
> >
> >I have my new alpha-server running Digital Unix 4.0b where I need to
> >transfer
> >all the users and where I need to enable "Enhanced Security".
> >
> >How can I transfer all the users without having 3000 people calling me
> >by the phone at the same time asking why they can't login ???
> >('cause enhanced security has locked their accounts without explanation)
> >
> >Is there an automated process I can use to transfer users? (under
> >Enhanced Security)
> >Is there a way to access the password fields contained in the database created
> >by enhanced security? (This to create a script to automate all the process and
> >mail people with their new (system generated) passwords before the change is 
> >made)
> 
> 
> I've done what you're attempting more than once, and I can tell you that it
> can be done seemlessly, so that your users don't even know about the
> change.
[..]
> 
> Here's what I recommend you do:
> 
> 0) read the man pages for `convuser', `edauth', and `prpasswd(4)', at a
>     minimum.
> 
> 1) on the new system, running 4.0b, 
> 
>     *before you copy over any of the password entries from the old system*
> 
>  a) install the latest patch set (#6), especially the account maintenance
>     tools.
>  b) if you haven't already switched the system to enhanced security, do
>     so. (either from the CDE task list or from `secsetup').
>  c) start up `dxaccounts' and set the system defaults and account defaults.
>     Some things you may want to change are the password controls (we let
>     people choose), the triviality checks (I recommend you enable the
>     triviality checks, but leave "site triviality checks" disabled unless
>     you want to write your own checks), the aging stuff (until you're
>     comfortable with enhanced security you may wish to disable this),
>     and the # of bad passwd attempts before the account will be locked.
>  d) you'll almost certainly want to change the "account locked" feature, so
>     that new accounts are *not* administratively locked.  You can re-enable
>     this feature after you've enrolled your users, if you wish.
> 
> 
> 2) once you've done 1a - 1d, you're ready to go!
> 
> 3) get the passwd file, with the encrypted passwds, from the other system.
>     Copy it over to the new (enhanced security) system.
> 
> 4) remove all the "system" (i.e. root, wnn, daemon, nobody, etc...) from
>     your old (base) security file.  You already have all those entries in
>     the new (enhanced) security file, and you don't want to add them twice.
> 
> The rest of this could be done in multi-user mode, but I recommend you do
> it with the machine to yourself (single-user mode with filesystems mounted
> and such works just fine).
> 
> 5) lock the passwd file (not really necessary if you're doing this in
> single user mode):
> 
>         mkdir /etc/ptmp
> 
> 6) build a list of users in your old (base) passwd file, for later use:
> 
>     cut -d : -f 1 old-passwd-file > list-of-users
> 
> 7) merge in the old (base) passwd file into the current (enhanced) file.  You
>     can either do this by
> 
>         cat old-passwd-file >> /etc/passwd
> 
>     or you can start up vi (not vipw, since you've already got the passwd
>     file locked and vipw won't let you merge in the base passwd anyway,
>     since it's going to complain that "you mangled the temp file").
> 
> 8) once you have the passwd files mixed together, run
> 
>     rm -f /etc/passwd.dir /etc/passwd.pag
>     pwck 
> 
>   to verify that you haven't hosed anything up.  Expect to see some warnings
>     about the system accounts not having shells, etc.  If you get other errors
>     (duplicate accounts, logins with bad fields, etc), you'll probably want
>     to fix those errors before you move forward.
> 
>     At this point, it may be a good idea to also run
> 
>     authck -a -v
> 
>     to make sure that your enhanced security files are all ok too.  You'll
>     run it again later after creating C2 profiles for all the users.
> 
> 9) if you locked the passwd file, unlock it:
> 
>     rmdir /etc/ptmp
> 
> 10) rebuild the hashed passwd database:
> 
>     mkpasswd -v /etc/passwd
> 
> 11) Pick a test user to convert to enhanced security.  Note what the person's
> encrypted passwd looks like.  Then do:
> 
>         /usr/tcb/bin/convuser -a -i -u <username>
> 
>     After doing this, run
> 
>         /usr/tcb/bin/edauth -g <username>
> 
>     verify that
> 
>         a) their encrypted passwd (u_pwd=) is the same in their C2
>         profile.
>         b) they have a field that says   u_oldcrypt=2
>         this is the C2's way of indicating that their old passwd was encrypted
>         using regular Unix crypt().  This really only makes a difference if
>         they type more than 8 characters at the passwd prompt, since crypt()
>         only uses 8 characters.  `convuser' should stick this field in by
>         default.
>         c) their account isn't administratively locked.  This is why it's
>         important to set the system defaults before converting users, since
>         convuser picks up on that default.  Their account is *not* locked if
>         it contains an entry like:
> 
>                 u_lock@
> 
>         Their account *is* locked if it contains:
> 
>                 u_lock
> 
>         If neither are there, it's based on what's in the system default
>         profile, which you can check with:
> 
>                 /usr/tcb/bin/edauth -g -d d
> 
>     Once you've verified that the account was converted the way you want,
>     you're ready to do the entire batch.
>     
> 12) Create an enhanced security profile for each of the users you moved from
>     the old system.  The idea is
> 
>         foreach user from the old system
>             /usr/tcb/bin/convuser -a -i -u <username>
> 
>     (You may also want to use the `-c' option to convuser, since you only
>     want to create new profiles).
> 
>     I generally do that like this, from the shell (this is Bourne shell
>     syntax):
> 
>         for i in `cat list-of-users`
>         do
>             /usr/tcb/bin/convuser -a -i -u $i
>         done
> 
> 
>     "list-of-users" is the file containing just usernames that you built 
>     in step 6.  Be sure you remove the test user from step 11) from your list
>     of users.
> 
>     Be advised that the time it takes to convert users in this manner
>     increases *more than linearly* with the number of users you have in your
>     passwd file.  
[ .... ] 
>     With only 3000 accounts, I would guess it will take 30 minutes to as much
>     as 2 hours to convert everyone.
> 
> 
> That should be about it!  Let me know how it goes.
> 
> Tim
> -- 
> Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
> Information Technology Services         (701) 231-1076 (Voice)
> Room 242-J1, IACC Building              (701) 231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
> 
> 
> 


I also would like to thank:

Spider Boardman <spider@Orb.Nashua.NH.US>
Kraizelman Riva <phsriva@physics.technion.ac.il>
Kevin Reardon <kreardon@na.astro.it>
Henrik Lynnerup <lynnerup@post9.tele.dk>


Bye.