SUMMARY: C2 auth database...

From: Saar Picker <saarp_at_uclink4.berkeley.edu>
Date: Fri, 19 Mar 1999 11:13:01 -0800

Thanks to:
        John Speno
        Martin Mokrejs
        William H. Magill
        Robert Mulley
        John Ferlan

Turns out the locked box was getting set due to the passwords being expired
which is not the behavior I remember seeing in DU40d. Thanks to all for the
quick responses and helpful information. I was writing this in perl so I
didn't have access to some useful system calls.

Responses below.

-Saar

-------- Original Message --------
Subject: C2 auth database...
Date: Wed, 17 Mar 1999 18:26:25 -0800
From: Saar Picker <saarp_at_uclink4.berkeley.edu>
Reply-To: saarp_at_socrates.berkeley.edu
To: tru64 <tru64-unix-managers_at_ornl.gov>


Hello all,

I've been wrestling with the intricasies of the C2 auth structure to
try and determine which accounts are about to have their passwords
expire. I've got the basic check for password expiration down by grabbing info
from /etc/auth/system/default about password lifetime and taking the
difference from the last successful password changetime for each user using
edauth. However, I'd like to exclude users that are locked, retired, cannot
log in, etc...

I happened upon an account that I thought had been locked, yet edauth -g
showed u_lock_at_ (meaning the user was not locked). When I bring up dxaccounts,
the gui shows the account as being locked. This is on a DU4.0b patchkit #7
alphaserver 2100rm. The user entry looks like this:

regtmf:u_name=regtmf:u_id#204:u_pwd=<passwd omitted>:u_exp#0:\
        :u_succhg#873730344:u_unsucchg#841875793:u_genpwd_at_:u_pwdict=<pwdict
omitted>:\
        :u_genchars_at_:u_genletters_at_:u_oldcrypt#0:u_suclog#886606394:\
:u_suctty=INET#sis107.Berkeley.EDU:u_unsuctty=INET#sis107.Berkeley.EDU:u_unsuclog#891618324:u_numunsuclog#4:\
        :u_lock_at_:chkent:

(excuse the messiness)

Another interesting thing I've run across is an account can be locked by
having u_pwd equal to any one of: "*Nologin", "Nologin", "nologin", "*".

Is this normal? Has anyone else delved this deeply into C2?

Thanks for any info.

-Saar Picker



========================================


Subject: Re: C2 auth database...
   Date: Wed, 17 Mar 1999 21:38:18 -0500
   From: John Speno <speno_at_isc.upenn.edu>
     To: saarp_at_socrates.berkeley.edu
References:
          1




>
:u_suctty=INET#sis107.Berkeley.EDU:u_unsuctty=INET#sis107.Berkeley.EDU:u_unsuclog#891618324:u_numunsuclog#4:\

I can't test this right now, but might u_numunsuclog#4 be which is causing
the account to be locked (or reported as locked by that god awful
dxaccounts thingy)?

===================================

Subject: Re: C2 auth database...
   Date: Thu, 18 Mar 1999 05:02:55 +0100 (MET)
  From: Martin Mokrejs <mmokrejs_at_natur.cuni.cz>
    To: saarp_at_socrates.berkeley.edu




>
> Another interesting thing I've run across is an account can be locked by
> having u_pwd equal to any one of: "*Nologin", "Nologin", "nologin", "*".

I communicated with half a year ago with the maintainer of dxaccounts at
Digital and he promised that he fixed this problem. It should be fixed in
#7, or if there's never patch, install it. Otherwise check again
installation dependencies.

The above applies *Nologin applies to password field of /etc/passwd.
Search archive for my posts on this topic.

This lock wasn't anyhow related to C2, dxaccounts were simply looking for
the string into /etc/passwd.

--
Martin Mokrejs - PGP 5.0i key at: finger://mail.natur.cuni.cz/mmokrejs
<mmokrejs_at_natur.cuni.cz> Faculty of Science, The Charles University
======================================
  Subject: Re: C2 auth database...
     Date: Thu, 18 Mar 1999 16:53:46 +1100
     From: Robert Mulley <robert_at_gnsconsulting.com.au>
 Reply-To: robtert_at_gnsconsulting.com.au
       To: saarp_at_socrates.berkeley.edu
 References: 
          1
Hello,
I would be interested to no what the /etc/passwd entry is for this
person. Aside from you maybe having changed the unsuccessful log in
count to 4 or below. Then all I can think is that the entry in
/etc/passwd has some lock type function.
Robert Mulley
Unix Administrator
GNS Consulting
========================================
Subject: Re: C2 auth database...
   Date: Thu, 18 Mar 1999 09:19:21 -0500
   From: John Ferlan <ferlan_at_zk3.dec.com>
Organization: Compaq Computer Corporation
     To: saarp_at_socrates.berkeley.edu
References: 
          1
>  However, I'd like to exclude users that are locked, retired, cannot
> log in, etc...
see the man page "locked_out_es(3)"
As for the particular account you list - perhaps the answer lies in the
difference in time
between today and the
last successful login/change...  read the man page it will potentially help
you answer the
question of how to
figure it out...
>  Has anyone else delved this deeply into C2?
Sometimes I think - unfortunately yes ;-)  of course it pays the bills for
me...
--
John Ferlan   DTN: 264-0854  Office: ZKO3-3/Y26
Compaq Computer Corporation
110 Spit Brook Rd.
M/S: ZKO3-3/W20
Nashua, NH 03062-2698
Phone: (603)884-0854
John.Ferlan aT digital dOt com
ferlan aT zk3 dOt dec dOt com
johnferlan aT iname dOt com
Any of the above will get mail to me.
To reply read above and figure it out_at_
Spammers can cheerfully send mail to:
 uce_at_ftc.gov
 root_at_localhost
 webmaster_at_localhost
 postmaster_at_localhost
=====================================
Subject: Re: C2 auth database...
   Date: Thu, 18 Mar 1999 10:12:48 -0500 (EST)
  From: "William H. Magill" <magill_at_isc.upenn.edu>
    To: saarp_at_socrates.berkeley.edu
>   I've been wrestling with the intricasies of the C2 auth structure to
>   try and determine which accounts are about to have their passwords
>   expire. I've got the basic check for password expiration down by grabbing info
>   from /etc/auth/system/default about password lifetime and taking the
>   difference from the last successful password changetime for each user using
>   edauth. However, I'd like to exclude users that are locked, retired, cannot
>   log in, etc...
>
See  Randy M. Hayman's "zuausr" for good stuff. Randy left U Alaska, so it
hasn't been updated lately.... source was at their ftp site.
It has reports and etc, but it is still using the 3.x TCB format (flat text
file), all you need do is to add in the database reads.
>   I happened upon an account that I thought had been locked, yet edauth -g
>   showed u_lock_at_ (meaning the user was not locked). When I bring up dxaccounts,
>   the gui shows the account as being locked. This is on a DU4.0b patchkit #7
>   alphaserver 2100rm. The user entry looks like this:
>
>   regtmf:u_name=regtmf:u_id#204:u_pwd=<passwd omitted>:u_exp#0:\
>          :u_succhg#873730344:u_unsucchg#841875793:u_genpwd_at_:u_pwdict=<pwdict
>   omitted>:\
>          :u_genchars_at_:u_genletters_at_:u_oldcrypt#0:u_suclog#886606394:\
>
:u_suctty=INET#sis107.Berkeley.EDU:u_unsuctty=INET#sis107.Berkeley.EDU:u_unsuclog#891618324:u_numunsuclog#4:\
>          :u_lock_at_:chkent:
>
>   (excuse the messiness)
>
>   Another interesting thing I've run across is an account can be locked by
>   having u_pwd equal to any one of: "*Nologin", "Nologin", "nologin", "*".
>
>   Is this normal? Has anyone else delved this deeply into C2?
>
Yes. Think about it.
The account is NOT "administratively" locked (u_lock); it is "password"
locked. 
A) u_pwd IS the users password - encrypted.
B) any plain text is guaranteed to be unusable as a password
C) prefixing the password field with one character is a convenient way to
        lock accounts for software (like POP) which does NOT honor C2
        security, but only looks at the shadow-password entry.

Received on Fri Mar 19 1999 - 19:15:37 NZDT