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_at_
>
> 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_at_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_at_Orb.Nashua.NH.US>
Kraizelman Riva <phsriva_at_physics.technion.ac.il>
Kevin Reardon <kreardon_at_na.astro.it>
Henrik Lynnerup <lynnerup_at_post9.tele.dk>
Bye.
Received on Thu Feb 05 1998 - 17:05:09 NZDT