[windows2000] Re: Why isn't everyone being forced to change their pass

  • From: "Greg Reese" <GReese@xxxxxxxxxxxxxxxx>
  • To: <windows2000@xxxxxxxxxxxxx>
  • Date: Wed, 13 Aug 2003 10:12:44 -0400

Sometimes you have to beat them down with a stick to get the whining to stop.  
I have never had to beat down more that one at a time to get the message across 
to everyone. I changed someone's password to "iwillnotarguewithIT" and revoked 
his ability to change it.  I have heard no whining from that building since.  I 
let him off the hook after a few weeks and we all had fun with it.

Greg

-----Original Message-----
From: Sorin Srbu [mailto:Sorin.Srbu@xxxxxxxxxxxxx]
Sent: Wednesday, August 13, 2003 10:07 AM
To: windows2000@xxxxxxxxxxxxx
Subject: [windows2000] Re: Why isn't everyone being forced to change
their pass


On Wed, 13 Aug 2003 09:01:02 -0400, Greg Reese wrote:

>we require some numbers to be mixed in with their password.  You have to find 
>a balance between too easy and too tough.  Too easy and it will be cracked in 
>the blink of an eye and too tough and they will just write it down on a post 
>it note and stick it on the front of their monitor.  We have one user who 
>prints their password on a ptouch and then affixes it to the top of their 
>keyboard.
>
>I always tell people to use an old street address as a password.  Easy to 
>remember and difficult to crack.  1234mainst for example.

Ah, of course. I also implemented the password complexity feature
as a domain-wide GPO on our DCs. I got some initial complaints from
users not being able to use their regular
"abc123"-type-of-passwords...


>-----Original Message-----
>From: Sorin Srbu [mailto:Sorin.Srbu@xxxxxxxxxxxxx]
>Sent: Wednesday, August 13, 2003 4:00 AM
>To: windows2000@xxxxxxxxxxxxx
>Subject: [windows2000] Re: Why isn't everyone being forced to change
>their pass
>
>
>On Tue, 12 Aug 2003 12:51:47 -0700, Chris Berry wrote:
>
>>>From: "Sorin Srbu" <Sorin.Srbu@xxxxxxxxxxxxx>
>>>Umm... I think that is a university problem. The PhD-students at
>>>our lab never want to change their passwords. When I first started
>>>my work at the dept, the previous "sysadmin" told me he had managed
>>>to reach a consensus by having a 6 month period between changes. If
>>>the students would have had their way, it would have been 5 years
>>>or some such. I implemented, by force, a 2 month period for
>>>changing the pwds. I'd rather have it at one month though. I might
>>>do it stealthily anyway. >>8->
>>
>>My personal opinion is that monthly is way too frequent, I'd have to write 
>>my password down, I'd always be forgetting it, which pretty much defeats the 
>>whole purpose.  My policy is three months for relatively easy passwords or 
>>six months for hard ones.
>
>Our problem is not ppl writing up their passwords on notes that
>they stick to the monitor, but easy passwords which can be
>brute-force cracked. The physical environment here is more or less
>locked down, so the sticky-notes are not that much of a problem
>really.
>
>Being an open (well, relatively...) university network we have a
>much bigger problem with hack-attacks and intrusion attempts.
>
>The unix-sysadmin agrees on this approach, and he's way more
>paranoid than me. 8-)
>
>
>BW,
>
>Sorin
>
># Sorin Srbu, Systems Engineer         Web: http://www.farmfak.uu.se/organisk/
># Dept of Medicinal Chemistry,         Phone: +46 (0)18-4714482 >> 5 signals 
>>> GSM
># Div of Org Pharm Chem,                       Mobile Phone: +46 (0)701-718023
># BMC, Box 574, Uppsala University     Fax: +46 (0)18-4714474
># SE-751 23 Uppsala, Sweden            Visit: BMC, Husargatan 3, D5:512b
>#
># Public PGP key available on request.
>#
># ()  ascii ribbon campaign - against html e-mail 
># /\
>
>
>********************************************************
>This Week's Sponsor - RTO Software / TScale
>What's keeping you from getting more from your terminal servers? Did you know, 
>in most cases, CPU Utilization IS NOT the single biggest constraint to scaling 
>up?! Get this free white paper to understand the real constraints & how to 
>overcome them. SAVE MONEY by scaling-up rather than buying more servers.
>http://www.rtosoft.com/Enter.asp?ID=148
>**********************************************************
>To Unsubscribe, set digest or vacation
>mode or view archives use the below link.
>
>http://thethin.net/win2000list.cfm
>********************************************************
>This Week's Sponsor - RTO Software / TScale
>What's keeping you from getting more from your terminal servers? Did you know, 
>in most cases, CPU Utilization IS NOT the single biggest constraint to scaling 
>up?! Get this free white paper to understand the real constraints & how to 
>overcome them. SAVE MONEY by scaling-up rather than buying more servers.
>http://www.rtosoft.com/Enter.asp?ID=148
>**********************************************************
>To Unsubscribe, set digest or vacation
>mode or view archives use the below link.
>
>http://thethin.net/win2000list.cfm



BW,

Sorin

# Sorin Srbu, Systems Engineer          Web: http://www.farmfak.uu.se/organisk/
# Dept of Medicinal Chemistry,          Phone: +46 (0)18-4714482 >> 5 signals 
>> GSM
# Div of Org Pharm Chem,                        Mobile Phone: +46 (0)701-718023
# BMC, Box 574, Uppsala University      Fax: +46 (0)18-4714474
# SE-751 23 Uppsala, Sweden             Visit: BMC, Husargatan 3, D5:512b
#
# Public PGP key available on request.
#
# ()  ascii ribbon campaign - against html e-mail 
# /\


********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you know, 
in most cases, CPU Utilization IS NOT the single biggest constraint to scaling 
up?! Get this free white paper to understand the real constraints & how to 
overcome them. SAVE MONEY by scaling-up rather than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=148
**********************************************************
To Unsubscribe, set digest or vacation
mode or view archives use the below link.

http://thethin.net/win2000list.cfm
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you know, 
in most cases, CPU Utilization IS NOT the single biggest constraint to scaling 
up?! Get this free white paper to understand the real constraints & how to 
overcome them. SAVE MONEY by scaling-up rather than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=148
**********************************************************
To Unsubscribe, set digest or vacation
mode or view archives use the below link.

http://thethin.net/win2000list.cfm

Other related posts: