Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!apollo.hp.com!pato From: pato@apollo.HP.COM (Joe Pato) Newsgroups: comp.sys.apollo Subject: Re: Unable to update /etc/passwd or registry. Not owner Message-ID: <509e3823.20b6d@apollo.HP.COM> Date: 27 Mar 91 17:26 GMT References: <738@bcstec.boeing.com> <508085fb.20b6d@apollo.HP.COM> Sender: root@apollo.HP.COM Reply-To: pato@apollo.HP.COM (Joe Pato) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 29 In article , rtb@cernapo.cern.ch (Rainer Tobbicke) writes: |> Actually, together with a collegue we have traced the problem down to |> a change to the user's name: in order to put a user into another |> group, we use /etc/edrgy and 'c account.group.org -n acount.newgroup.org'. |> This seems to do what you would do with a vi of /etc/passwd on a vanilla |> Unix system, the user ends up in group 'newgroup' (I'm aware that this |> creates a mess in his file base). |> |> After this the poor guy cannot change his default shell any more...! |> This is a bug, but with a simple workaround. When you use the edrgy change command to change an account's name (in order to change the default group associated with the account), it will not preserve the user's authentication key. A new key is generated. A user who is currently logged in will have the old key and therefore not be able to authenticate properly. The problem should go away after the user logs in anew - unfortunately the change to the account record neglected to update a flag associated with the authentication info that would have made this work correctly. This problem will go away if the administrator sets a new password for the account and the user logs in with the new password. - Joe Pato Cooperative Computing Division Hewlett-Packard Company pato@apollo.hp.com