Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security

Synchronizing Forced Password Changes? 51

aroobie asks: "I have several different types of servers running at my small office including Windows 2000 Advanced Server, VMS, IRIX, and Linux. My corporate parent wants to force passwords to change every 90 days, which is a good thing, but once a user changes his/her Windows password access to the other servers is denied until I make appropriate changes on the non-Windows servers. Sort of defeats the purpose of changing the password since each users has to give me their new password to make them match on on the servers. Has anyone found a way to synchronize passwords on different systems? Is there software available to do this?"
This discussion has been archived. No new comments can be posted.

Synchronizing Forced Password Changes?

Comments Filter:
  • winbind (Score:5, Informative)

    by dago ( 25724 ) on Wednesday October 09, 2002 @04:52AM (#4415441)
    winbind [advogato.org] may be a possible solution : your unix boxes authenticate to the NT domain

    Winbind is an nss switch module to map Windows NT Domain databases to Unix.

    In combination with Samba and pam_ntdom, a Unix box will be able to integrate straight into a full Windows NT Domain environment, without needing a Unix Account database.

    Use of pam modules (pam_smb, pam_ntdom) also works (on pam systems like linux or solaris) very well.

  • Any computer geek could answer you with one word: ldap, why did yo want to ask on slashdot?
    • The supposed benefit of using Ask Slashdot is to get a wide range of opinions on a matter. Granted that a person may run into some stories of experience in the newsgroups, they won't find nearly as much.

      I'm sure they know of ldap, kerberos, blah, blah, blah... but which should they use? What do their peers think? What have their peers experienced?

      Nothing like Unix geeks. We bitch at all the horrible sys admins (mostly Windows, of course ;^), then we redicule them when they ask for our help.

  • not so simple (Score:2, Insightful)

    by NotInTheBox ( 235496 )
    At the university we sometime need it the other way around... linux password has to be converted to Windows passwords.

    It works like this: the program asks for you password, which it then validates/authenicates
    with the yppasswordd if approved (this means that the string just typed is indeed the one and only true password) it asks a windowsNT box to associate know username to new password.

    Don't know if this could also be done in reverse however. Platform independant accounts would be a great plus. Anyone else having a idear?
  • by fluor2 ( 242824 ) on Wednesday October 09, 2002 @06:09AM (#4415592)
    Microsoft actually made a program that syncs with Novell passwords. (Here) [microsoft.com]. For Unix, use this link [microsoft.com] for finding more information. Especially this [microsoft.com] and this [microsoft.com].
    • The lab [microsoft.com] for the UNIX password sync tool includes the following instruction:

      3.
      Telnet to UNIX machine, and verify that now you have to log on to user2 with the new password.


      The emphasis on "Telnet" is mine.

      I have to say that I am hesitant to use any security product whose instructions include the word "telnet" without preceding it with the words "do not use."

      -Peter
    • by Krelnik ( 69751 ) <`moc.gnirpsdnim' `ta' `yelrafmit'> on Wednesday October 09, 2002 @12:42PM (#4417349) Homepage Journal
      FWIW, these tools that Microsoft provides (see excellent links in parent message) are actually built on a Windows API that is publicly documented [microsoft.com] (see "password filter") and they even offer free sample source code [microsoft.com].

      So if you have some home-grown system you need to sync with, or you just like to roll your own solutions, you can do it. Essentially there is a DLL you load on the server that gets called every time a password is changed. It can then approve or deny the change, but more importantly since it sees the password it can do the sync. This is how the PASSFILT.DLL [microsoft.com] is implemented as well as the Novell and Unix solutions mentioned in the parent of this post.

  • by perljon ( 530156 ) on Wednesday October 09, 2002 @06:19AM (#4415607) Homepage
    Software to automatically do this stuff is kind of expensive. YOu could roll your own package for pretty cheap, if you force everyone to change their password at the same place. For example, it would be easier to force all of your users to go to http://changepassword.yourorg.net to change their password.

    Then, take their new password and set it in each system using perl (I'm sure it either has a library for each system you are talking about or you can drop out to a shell from perl to change passwords via the Unix shell.)

    The hard part about using one system to change all passwords, ie, having all passwords set from you Windows Box or from your Unix shell is that without special software, each system does a pretty good job making sure you don't know what the password is by using several schemes to hide and encrypt it (that's important...). By forcing everyone to change it in one place, you avoid having to buy the propietary libraries which notify a central system of a password change.

    If that sounds too complex, get ahold of me, and I'll be happy to help more for a small fee or some barter.
  • ummm... (Score:2, Flamebait)

    by quinto2000 ( 211211 )
    Kerberos, among other options. You're describing a very common problem, for which dozens of solutions exist. It seems a waste of an Ask Slashdot question, IMHO.
  • LDAP (Score:1, Informative)

    by retards ( 320893 )
    Couldn't you use LDAP as a centralized authentication service? I think that's the way we're going at work with our Windows/*nix password synchronization.
    • Re:LDAP (Score:2, Informative)

      by velkro ( 11 )
      Works good here. Novell's eDirectory has a pwdsyunc module available to sync info/passwords with Active Directory too.

      Linux, Lotus, MS, Nortel products all happy, as well as internal apps too.
      • velkro said:
        > Works good here. Novell's eDirectory has a pwdsyunc module available to sync info/passwords with Active Directory too.

        Novell has got more than just one product that can fit this bill - DirXML [novell.com] can synchronize passwords (along with IDs, groups, etc) between eDirectory and NT domains or Active Directory with the Password Sync module (all three pieces now come free with Zen for Desktops 4, BTW), Novell Account Management [novell.com] can synchronize to Mainframe and Unix platforms as well as Windows, not to mention the whole single-signon/Secure Login [novell.com] family of products.

        The difference between the various products is partially focus (identity management versus password synch), and partially the choice of authoritative sources (DirXML is VERY flexible).
  • I don't know of any Windows tools that will make it directly authenticate via ldap. However, if you run Samba, you can have it store its passwords in ldap. That'll give you unified passwords on the Windows and Unix machines.

    VMS...I don't know.
  • by Eagle7 ( 111475 ) on Wednesday October 09, 2002 @07:30AM (#4415742) Homepage
    I don't know why people harp on about changing your password as a matter of policy. In my experience, this just means that employees will find the simplest system that satisfies the hueristics, and end up with insecure passwords - such as j0e01, 02j0e, j030e, j004e, j0e05, etc - since coming up with f$6hq7# and remembering it every 90 days is a PITA. So your policy makes someone who *would* choose a secure password choose insecure ones becuase they don't want to keep switchng. (or worse, they write them down!!!)

    On the other hand, you could educate employees on the benefits of secure passwords, tell them that as long as the pick a secure password, never share it, and never write it down, they can keep it. Yeah, some people will break the rules - but they'll have insecure passwords under any circumstances. But the folks who actually try will end up more secure.

    After all... as long as I protect its use and don't share it or record it, f$6hq7# is as secure in a year as it was the day I defined it.

    • After all... as long as I protect its use and don't share it or record it, f$6hq7# is as secure in a year as it was the day I defined it.


      Not anymore :)
    • by Bazzargh ( 39195 ) on Wednesday October 09, 2002 @07:55AM (#4415800)
      Reminds me of one of my old corporate's security faux pas...I rarely used the crappy mainframe system, so quite often when I did my password had expired and I had to call the helpdesk to get it reset...

      Me: I need a password reset
      Drone: Fine, whats your name and secure PIN?
      Me: John Doe, username ******, pin no ****
      Drone: hang on...that doesnt appear to be correct, are you sure thats the PIN?
      Me: Yes, I've been using that PIN for years[1]
      Drone: ok, I'll reset your PIN to ****[2]
      Me: thanks, can you reset my password then?
      Drone: sure...your password is now ******. thanks for calling
      *click*[3]

      [1] herein being the first flaw in the security system. The passwords dont change, but if you can guess the PIN you can get it reset (and its only 4 digits)
      [2] and here's the doozy. I could have been anyone, and now I have got the PIN reset. Internal security tried to get hold of me when I mentioned this incident on a company newsgroup, presumably to sack the person that reset my PIN.
      [3] Mission accomplished, identity stolen. At this point I considered calling back claiming to be our venerable CEO.
    • by perljon ( 530156 ) on Wednesday October 09, 2002 @09:14AM (#4416141) Homepage
      Some how, 30 days after you set the password to f$6hq7#, it was compromised. Even though it was a great password, I grabbed the /etc/passwd file and brute forced it, or I sniffed your password when you used telnet instead of ssh, I looked in through a window and a telescope and watched your fingers, I put a keyboard sniffer on your keyboard, I used high-tech equipment to detect the electrical impulses from the key, or I even watched you type it in (after all, it takes a little longer since you are a pecker instead of a typer.) Long story short, I grabbed your password. If you have passwords reset every 90 days, I have only compromised your password for 60 days instead of a year.

      The trick is educating your users on how to create good passwords from pass phrases. ie, I like to buy expensive high tech toys becomes IlTbEhTt Now, do some number replacements for for Capital letters, you make the rules, but make your own. I will replace capital I's with 1's and Capital E's with 3's in this example. 1lTb3hTt What we come up with is an easily remembered password because you know the pass phrase and you know the algoryhtm you used to create the password. (took my last sentence, took the first letter, replaced I's with 1's, E's with 3's, o's with 0's.)
      • I am in full support of f$6hq7#

        You purpose all of these difficult measures in compromising it: brute force, sniffing, spying. If you were capable of doing it once, why can't you do it again? And if you are truly l33t you would have a backdoor, so that changing my password wouldn't lock you out.


        Now go back to what the original poster was talking about. Frequent password changes make users choose simple passwords and/or write them down. I have seen this in practice too many times to count. So now you don't need to brute force my password, just look for a sticky note or run a dictionary attack. This gets worse as I visit 10 sites a day that want a password from me; how can I remember them all?

        • Security is like an onion. On the outside layer, everyone who walks into the office can log onto a computer and do whatever he wants using the publicly posted password. This is a trush system, and although very insecure is the cheapest solution. Peel the layer, and you introduce a private username and password that only those on the inside know. Peel a layer, and everyone gets there own username/password. Peel a layer, and everyone gets there own hard to guess/hard to crack password. Peel a layer, and everyone gets a hard to guess/hard to crack changing every 90 days password.

          Also, at each layer you introduce stuff like encryption, good physical security, regular auditing, etc. etc. etc. With each layer, you pay a little more money, at least in administration costs and complexity.

          To my point, is changing your password every 90 days going to fix all security problems? No... However, it is a cheaper solution to implement than it is to crack, so it's a no brainer to implement the policy.

          But I agree, if you don't do good in other arenas, there is little hope. In a secure environment, regular audits are done. Hopefully, backdoors and open telnet ports are found and fixed. Then when the password is changed or the patch is applied that doesn't allow a cracker to use an exploit to gain the passwd file, you've effectively locked out the cracker.

          It's not the end-all be-all security solution, but combined with other security techniques it is affective for a small cost.
      • it's even more ignorant to think that it's more damaging to have a breach in security for 60 days than, 30, or 15. If you're going through the trouble of gaining someones login, and you actually plan to do something wrong with it, you aren't going to sit on your thumbs. Unless you're changing your password every 12 hours, the timing is relatively* irrelevant.

        Consider this - I brute force your password, and there are 5 days left before your 30 day password reset. I slap in some custom sneaky aliases for your default shell that look exactly like the password changing utility, and in fact change your password - but lo and behold, it also a> logs it to a file I can read, b> emails it to me, c> insert_random_too_late_you're_already_screwed_acti on_here

        good thing you reset your password, I almost got in!

        * [obviously using the same password everywhere for years sucks because you'll mistype it somewhere in an IRC channel or the wrong window or in front of someone at SOME point, and then it really should be changed - if it's a strong password, it'll be obvious that it's not just a "wrong window" IM/chat reply]
        • * [obviously using the same password everywhere for years sucks because you'll mistype it somewhere in an IRC channel or the wrong window or in front of someone at SOME point, and then it really should be changed - if it's a strong password, it'll be obvious that it's not just a "wrong window" IM/chat reply]

          So you agree that password aging is a good idea. I'm glad we could come togethor on this.
      • You know, doing "warez" replacements on letters is awfully easy for a piece of software to do.

        If I was writing a password cracker, the first thing I'd have it do is try substituting "3" for "E", etc.

        Yet people always have this smug feeling that "warezifying" their password (where the original is often common English) has just made it unbreakably secure. Oh, or tacking a "1" on the end of it.

        More importantly, if you're working with non-shadowed passwords and can glean *any* passwords from /etc/passwds, there are more serious security issues than some user choosing a weak password.
        • But when using a unique passphrase, "warez" replacements only serve to make the password harder to crack with a brute force attack by increasing the possibility of characters.

          I agree with you that replacing numbers for letters does nothing to make the password any more secure if it is based off a dictionary word. ie, turning password into p@ssw0rd doesn't really help that much.

          However, starting with the pass phrase "I like to pick very difficult passwords to crack", you get IlTpVdPtC which will never be in a dictionary. However, brute forcing this will take a lot longer if you say "1lTp7dP2C". Also, the key is to develope your own rules, but are easy to remember. For example, substituting numbers for entire words. "I am happy because I have a Full Life" "IaHbIhAfL" becomes "Ia3bIhA24L" because your personally defined system 3 equals happy because you have 3 kids and 24 is full because that's how many hours are in the day. It doesn't matter what your systems is as long as it is only stored in your head, it is easy to create passwords and to remember passwords with, and it makes the password especially difficult to a) guess b) crack with a dictionary c) brute force be trying every combination of letters, capital letters, and numbers.
      • one of my favorite passwords (well, passphrase is more like it) is a variant of this one:

        This is a very long password, that is easy to remember and almost impossible to brute force, because it is too long and contains 200 characters, so you can just eat shit stupid fuckhead administrator!

        You could even change it a bit, and make it provokative:

        My password is a very long password, that is easy to remember and almost impossible to brute force, because it is too long and contains 201 characters, so you can just eat shit stupid fuckhead bastard!

        It's always fun to recite that password to anyone who asks :-)

        Okay, so it's not the easiest password to enter, but it's rather effective, and (I would almost bet) it is impossible to bruteforce it with a simple keygen ... hehe
  • by DrSkwid ( 118965 ) on Wednesday October 09, 2002 @07:48AM (#4415769) Journal
    single secure sign-on for multiple domains

    here [bell-labs.com]
    or
    [pdf]

  • LDAP, of course. (Score:4, Informative)

    by -dsr- ( 6188 ) on Wednesday October 09, 2002 @07:50AM (#4415779) Homepage Journal
    Just run a central LDAP server. Everything you've mentioned can authenticate from LDAP. For details, just Google for LDAP and the OS name and "password".
    • LDAP is the correct solution. everything else is just a nasty hackarround....
    • Doing that with Windows 2000 brings up a bunch of links on the first page about security vulnerablities while using it over SSL. I'm sure these could be resolved but is it the best or cleanest solution?

      That's why I like Ask Slashdot over the "Ask Google" answers. You get people's experiences about what works and doesn't. You also get completely different solutions presented which might not have been so obvious during a Google search.

      Of course /. needs to stop posting questions that are so far out of scope. I.E. "I'm soley responsible for migrating an entire class B network to a new block in 30 days. I just passed my A+ test (boy was it hard) and was wondering what I should do next. Trust me, I know what I'm doing." There have been some very similar to that recently. Some of the discussions were interesting but most of the posters solutions wouldn't have worked on a scale much larger than a home network.
      • The company I work for has thousands of workstations and servers of various types accros various lan and wan networks, we used to use novel but migrated to LDAP about 6 months ago witout any problems.

  • Retarded (Score:1, Funny)

    by Skord ( 605246 )
    I have been working 24 hours solid at my admin job. My brain hurts. Don't give me any pain receptor bullshit. I have evolved pain sensors in my brain from days like this.

    I think tommorrow I might ask slashdot "how sambah wurks".

    Ignore me. I am the most overworked person in IT today.
  • by Pointer80 ( 38430 ) on Wednesday October 09, 2002 @09:18AM (#4416159)
    I'm not too familiar with VMS, but Linux can and IRIX might (not support is mentioned for it) be able to use the pam_ldap [padl.com]/nss_ldap [padl.com] modules from padl.com to authenticate against Active Directory. IIRC, this requires SFU, but I could be wrong. There is a document about it in the tarball for nss_ldap.

    Here's some links to Linux/AD integration from padl.com's doc section:

    Active Directory and Linux [securityfocus.com]

    Linux-AD Integration [ratisle.net]

    Active Directory and nss_ldap [www.hut.fi]

    /pointer
    • SFU works the opposite way, I think; it'll rexec or something over to your unix boxen and change the passwords. Or, I think, there's a daemon you can run on the UNIX boxen that the NT box'll call up and use that to change the password; safer than rexec.

  • how are they accessing the unix/vms servers?
  • Is using the same username and password for multiple (radically) different systems now considered good security policy? I must have been out of the sysadmin game too long... Sounds to me like a good way to reduce your UNIX system's security to the security of your Windows boxes.
  • Have them login to all applicable systems first, then change their password(s) all at once.

    Yeah - it's stupid, but unless the system has some ongoing authentication checking, it'll allow it. Since you need to change all the passwords at once anyway, it's not like it's "extra work" on the whole.

    Yeah - there's also a better solution, but if management wants to go this route, let 'em - and show them statistics on how weak the resulting passwords are (bonus points if the passwords were stronger before)

    dictionary attacks (with minor mutations) should always fail on a password, unless you're username is luser.
  • What I fail to understand is why people need to be forced to change passwords at all: why are all these systems single-layered?

    It only seems logical that smart-cards or java-enabled i-buttons... or whatever could provide improved security when combined with a password. I'm no cryptography expert, but it seems like a password or password hash doesn't have much more than 25 bits of real security.

    Is it just hardware that keeps this from taking off?

    Is there any support for password/smart card authentication systems in Linux?

"If it ain't broke, don't fix it." - Bert Lantz

Working...