From: Tom Linden (tom@kednos.com)
Date: Tue Sep 03 2002 - 19:18:54 EDT
Thanks goes to Denise Dumas [mailto:dumas@zk3.dec.com]
Original query
>Yes - that's it. Just try it in secconfig again - when you choose
>the enhanced -
>custom, on the 4th screen, in the top left corner, there is a box labeled
>Configure. Next to it is the text "breakin detection and evasion
>options". Click
>it, and the 4th line down is "Maximum unsuccessful login
>attempts". Change to 3
>and OK. I know this will change the user defaults. What I haven't
>figured out
>yet is where dxaccounts is picking it up from. Bug ...
>
>Denise
>
>Tom Linden wrote:
>
>> I went to the breakin evasion screen, and the number of unsuccessful
>> attempts had been reset. I changed it in the default template from
>> 5 to 3 using the slider. However, in looking at individual accounts
>> there was no change, and I suspect this is what you were referring to.
>>
>> Do you believe they would change upon reboot? Or is there some process
>> that could be killed and restarted?
>>
>> >-----Original Message-----
>> >From: Denise Dumas [mailto:dumas@zk3.dec.com]
>> >Sent: Tuesday, September 03, 2002 12:54 PM
>> >To: Tom Linden
>> >Subject: Re: Limiting login tries?
>> >
>> >
>> >5.1A and 4.0D are way different. There is no secconfig on 4.0D,
>it's called
>> >secsetup and it will try to force you to strict C2 standards.
>> >
>> >From dxaccounts, 5.1A, with enhanced security enabled (sounds
>like you've
>> >figured this out)
>> >View menu
>> >local templates
>> >click icon for default
>> >You'll get little window called Add/Modify
>> >choose Security
>> >Turn To - choose Login Restrictions
>> >
>> >Unlock interval - yes, what you said.
>> >
>> >The slider at the bottom, Maximum attempts, is supposed to be
>the number of
>> >failed logins before breakin evasion kicks in. However, altering
>> >it doesn't seem
>> >to update the per-user default value, which is weird. This may be
>> >broken - have
>> >to check. In any event, you can set this systemwide using
>secconfig on the
>> >"Breakin Evasion" screen. Ignore the reboot message. You can
>then alter it
>> >per-user in dxaccounts. hmmm....
>> >
>> >Don't set a grace limit - that's what you use to UNLOCK an account
>> >that has gone
>> >into breakin evasion (like vms set intrusion=0) To unlock an
>> >account early, give
>> >it a grace limit. This will allow a user with the correct password
>> >to log in
>> >even though the acct is disabled. A successful login resets
>lots of other
>> >variables. see locked_out_acct_es manpage.
>> >
>> >edauth -g will show you the raw user data. man prpasswd defines
>> >the fields. I
>> >know it's ugly - but if you really want to see ugly, 4.0D is even worse.
>> >
>> >Denise
>> >
>> >Tom Linden wrote:
>> >
>> >> Denise,
>> >>
>> >> I pulled up the default template that you suggested, but the help menu
>> >> doesn't quite correspond to what I am seeing. This is on
>5.1A, haven't
>> >> tried 4.0D yet. What is the Grace period? I assume that if
>all I want
>> >> to do is to limit the login tries to 3/hour then I set the that field
>> >> and the unlock interval to one hour?
>> >>
>> >> Tom
>> >>
>> >> >-----Original Message-----
>> >> >From: Denise Dumas [mailto:dumas@zk3.dec.com]
>> >> >Sent: Tuesday, September 03, 2002 11:54 AM
>> >> >To: Tom Linden
>> >> >Subject: Re: Limiting login tries?
>> >> >
>> >> >
>> >> >Hi,
>> >> >
>> >> >The security configuration suitlet is available from the sysman
>> >> >applications
>> >> >- see the configuration menu. When you build a system and log in
>> >> >as root for
>> >> >the first time, you can't avoid this menu - it will show up
>> >under "Custom
>> >> >Configuration". I don't even think you CAN make changes from
>> >> >Sysman Station
>> >> >- that is designed for daily monitoring.
>> >> >
>> >> >Tru64 defaults to "traditional" UNIX authentication, in which user
>> >> >authentication information is strictly limited to what is defined in
>> >> >/etc/passwd (/usr/include/pwd.h) format. And this is
>standard across all
>> >> >UNIXes, we can't change it. But in order to do breakin detection and
>> >> >evasion, we need to store more information (last failed
>login, number of
>> >> >permissible attempts). Stuff that will not fit in the
>> >(standardized) passwd
>> >> >structure. So every UNIX vendor has their own variation on
>how to store
>> >> >extra security info (as well as what to store, how to access it, ad
>> >> >nauseam).
>> >> >
>> >> >wrt VMS, two different authentication systems is not a problem
>> >that VMS has
>> >> >to deal with - sysuaf or zip ;-) It's a very different world when
>> >> >you define
>> >> >the interface! Same for Windoze.
>> >> >
>> >> >Denise
>> >> >(currently Tru64 engineering)
>> >> >(in a former life, VMS engineering)
>> >> >
>> >> >Tom Linden wrote:
>> >> >
>> >> >> Denise,
>> >> >>
>> >> >> I can see how to do this from command line aas you suggest,
>> >> >> but it isn't at all obvious how to do it from the SYSMAN Station
>> >> >> icon in CDE? Seems like I shouldn't have to delve into
>> >manuals for such
>> >> >> an intuitively simple task. Such is certainly the case on
>> >VMS and W2K.
>> >> >>
>> >> >> Tom
>> >> >> >-----Original Message-----
>> >> >> >From: Denise Dumas [mailto:dumas@zk3.dec.com]
>> >> >> >Sent: Tuesday, September 03, 2002 8:09 AM
>> >> >> >To: Tom Linden
>> >> >> >Subject: Re: Limiting login tries?
>> >> >> >
>> >> >> >
>> >> >> >Hi Tom,
>> >> >> >
>> >> >> >You have to use Enhanced Security to do this. Configure it
>> >with sysman
>> >> >> >secconfig, then examine user accounts using the dxaccounts
>> >gui. Look at
>> >> >> >the "default template" to set breakin evasion/detection
>defaults for
>> >> >> >all users, or you can change per-user.
>> >> >> >
>> >> >> >Denise
>> >> >> >Tru64 Security
>> >> >> >p.s. securiaty manual and rest of docset is online at
>> >> >> >http://www.tru64unix.compaq.com/docs/pub_page/doc_list.html
>> >> >> >
>> >> >> >Tom Linden wrote:
>> >> >> >
>> >> >> >> On our other machines running OpenVMS and W2K we limit
>> >> >> >> login tries to 3 per hour. How do we do this on 4.0d and 5.1a?
>> >> >> >> ---
>> >> >> >> Outgoing mail is certified Virus Free.
>> >> >> >> Checked by AVG anti-virus system (http://www.grisoft.com).
>> >> >> >> Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>> >> >> >
>> >> >> >---
>> >> >> >Incoming mail is certified Virus Free.
>> >> >> >Checked by AVG anti-virus system (http://www.grisoft.com).
>> >> >> >Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>> >> >> >
>> >> >> ---
>> >> >> Outgoing mail is certified Virus Free.
>> >> >> Checked by AVG anti-virus system (http://www.grisoft.com).
>> >> >> Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>> >> >
>> >> >---
>> >> >Incoming mail is certified Virus Free.
>> >> >Checked by AVG anti-virus system (http://www.grisoft.com).
>> >> >Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>> >> >
>> >> ---
>> >> Outgoing mail is certified Virus Free.
>> >> Checked by AVG anti-virus system (http://www.grisoft.com).
>> >> Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>> >
>> >---
>> >Incoming mail is certified Virus Free.
>> >Checked by AVG anti-virus system (http://www.grisoft.com).
>> >Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>> >
>> ---
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
>
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:51 EDT