SUMMARY:
OSF Enhanced Security
First of all, thanks to
Spider Boardman ... spider_at_Orb.Nashua.NH.US and
Stuart 'Zen' Bishop ... zen_at_RMIT.EDU.AU
who answered all of my questions.
Now, back to the subject:
here's what I asked:
> Hello Everyone:
>
> Recently, I installed the enhanced security system for osf v.3.0
> and I've had some problems. The machine I administer gives service to
> aprox. 900 students.
> So here are my specific questions:
> 1. When a user tries to log in (without success) to his/her account,
> the system 'locks' it. I was hoping that a security system would do that:
> disable it, but FOR A LITTLE WHILE, and then enable it again.
> Apparently, my system disables it, and I have to use the (in)famous
> XIsso manger to unlock it again. Imagine what happens when you have a
> big student population.... I spend lots of time enablig accounts. Is there
> a shortcut for this? Or , is this something I should have considered before
> installing the subsystem?
> 2. How can I disable more than 1 account with just one click?
> I know that templates may help me to do the trick, but I am not currently
> using templates.
> 3. Is it alright if I still use adduser? (again, XSysAdmin is terribly slow,
> and performs poorly)
The moral of the story is: If you can avoid installing the Enhanced
security subsytem AFTER you have created all your users, DO IT.
The optimal thing would be to install it in a 'clean' machine (i.e.
with no accounts). If you do install it afterwards (like I did), you're
gonna have to do some work.
1. My first question dealt with the locking mechanism of the subsytem.
Apparently, there is a typographical error in the
/etc/auth/system/default file.
the line that says:
u_unlockint
should read:
u_unlock.
Quoting:
"The "86400" associated with the unlock interval is the
number of seconds since the last unsuccessful login that must
have passed before the *count* of unsuccessful logins will be
ignored for purposes of determining whether the account should be
locked."
That number can be changed to whatever the need is. I use 3600 (1 hour),
so an account is locked only for 1 hour. The other parameter to play with
is the number of unsuccesfull logins.
2. The use of templates is absolutely NECESSARY if you have a large population
of users. If someone installs the subsystem on a machine with lots of accounts,
the thing to do is to write a small script that goes changing every users's
auth file. This script should add a line that adds a reference to a
previously created template (in the followin example, the previously
created template is called students). When using templates, if you want
to change some value or attribute, you change it in the template, and automatically,
all accounts asociated with the template will take the new vaule.
Here is an example for a valid minimal entry (/tcb/files/auth/s/s9002115):
s9002115:u_name=s9002115:u_id#3843:u_oldcrypt#0:\
:u_pwd=xxxx:\
:u_template=students:chkent:
Quoting:
"Note that the system insists that the indented lines start with a REAL TAB.
If you go through and modify all users tcb files to resemble the above
(just make sure you skip the important ones that come with the system:
root, auth, daemon - these have special entries in them) then you
will find managing the accounts is a lot easier. Most of the
information in the tcb entries can be safely trashed - you will just lose
password histories and stuff like that. There will be stuff you need to
trash so that it doesn't override the entries set for the templates."
3. Having done some tests myself, I can safely say that adduser
works with this subsytem. Be carefull, though. When XSysAdmin creates
a new template, it assigns a uid with a value higher than adduser
accepts as valid users id's. What I did was to change that uid to
a smaller number, so that adduser can work properly.
There is some code in adduser that creates the auth entry for each
user. You can modify that code to suit your needs. For example
you can add a line that references a template.
This is the revision date of my adduser script:
# _at_(#)$RCSfile: adduser.ksh,v $ $Revision: 1.1.10.2 $ (DEC)
this are some lines from my adduser script:
if [ -d /tcb/files/auth
]
then
ULETTER=`expr "${USER}" :
'\(.\)'`
AUTHDIR="/tcb/files/auth/${ULETTER}"
if [ ! -d "${AUTHDIR}"
]
then
mkdir -p
"${AUTHDIR}"
chown auth
"${AUTHDIR}"
chgrp auth
"${AUTHDIR}"
chmod 660
"${AUTHDIR}"
fi
if [ -f "${AUTHDIR}/${USER}"
]
then
dspmsg adduser.cat -s 2 1 'An auth database entry already exists
for (%1
$s)\n'
"${USER}"
else
cat > "${AUTHDIR}/${USER}" <<EOF
${USER}:u_name=${USER}:u_id#${UID}:\\
:u_pwd=Nologin:\\
:u_template=alumnos:u_lock_at_:chkent:
EOF
fi
chown auth
"${AUTHDIR}/${USER}"
chgrp auth
"${AUTHDIR}/${USER}"
chmod 660
"${AUTHDIR}/${USER}"
dspmsg adduser.cat -s 2 5 'Do you wish to edit the auth file entry
for this
user (y/[n])?
.....................(etc)
When creating the entry for the auth file, i added a reference to
a template called alumnos.
Hope this is usefull,
later,
Enrique
--------------------------------------------------------------
| Enrique Sanchez Vivar | E-Mail: |
| Centro de Computo | evivar_at_eniac.rhon.itam.mx |
| Grupo de Redes | |
| I.T.A.M. | |
--------------------------------------------------------------
Received on Thu May 11 1995 - 13:13:48 NZST