SUMMARY: Trouble with C2 security / shadow passwd

From: Jiri Dvorak (dvorak@iam.unibe.ch)
Date: Fri Jan 11 1991 - 07:21:05 CST


My question was:

  Last weekend I installed part of the C2 security features on our mixed
  Sun-3 (4.0.3) Sun-4 (4.1.1) configuration with servers and diskless clients.
  Due to space limitations I disabled the auditing (removed the auditd from
  rc.local). This way the only action of the C2conv script was the
  splitting of passwd and group files. With minor problems
  everything was running (NIS maps passwd.adjunct, group.adjunct and the
  rpc.pwdauthd daemon).
  But every morning, the first user on every workstation has to wait
  2-4 login timeouts before he/she can log in. The user is asked for name
  and password, and then the login process hangs until timeout.
  The console usually displays some 'rpc: RPC: Timed out' messages.
  (A ps -aux shows that the first rpc.pwdauthd is present, i.e. one with
  low pid)
  In average, the third attempt is successful and from then on the problem
  disappears for the rest of the day.

  Any idea what the problem is, and how it can be fixed?

  I have to add that one server per night goes down to singleuser for
  automated backups.

------------------------------------------------------------------------------

I received two answers:

 - Richard Elling <elling@eng.auburn.edu> pointed out that the culprit is
   with the server going down for backups during the night:
> rpc.pwdauthd will bind to it's NIS server differently than other NIS
> clients. Presumably, rpc.pwdauthd has this different mechanism
> to help prevent spoofing. I know of no workaround. A hack would be to
> have cron start a job which would cause rpc.pwdauthd to try to rebind,
> perhaps an rlogin or ftp. Then rpc.pwdauthd will be rebound by the tim
> your users login in the morning.

   And in fact, after a night without singleuser backups, the login procedure
   succeded at first attempt.

 - hal stern <stern@East.Sun.com> indicated that the problem may be caused
   by the fact that a 4.0.3 NIS master is serving 4.1.1 slaves and clients:
> if you're mixing 4.1 and 4.0.3 NIS masters, that's probably your
> problem. the 4.1 clients are trying to read 4.1-style NIS files,
> and will fail until they rebind to the 4.1 server. your NIS master
> server should be a 4.1 machine
 
   I didn't try this one, but we plan to upgrade our master server
   in a month or two. Looks as if it will be ok then.

Many thanks to all,
Jiri Dvorak



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:09 CDT