views:

221

answers:

4

We have several UNIX machines you can wind up with when you telnet to a certain box. The passwd files are not on a shared mount (I am not sure how safe it is to mount them anyway). The end result is that if you change your password on one box that when you login to the second box it will tell you that your password is invalid. This makes no sense to the end user since they typed telnet servername in both instances. Any pragmatic experience, advice, or pointers to help resolve this situation?

ENVIRONMENT CONTAINS

  • AIX 5.3, 5.2, 5.1, 4.3
  • HP 11 11.11 11.23 11.23I
  • Sun 10
  • Linux

UPDATE:

I am considering disabling passwd on all boxes except for one. passwd could then be a remote call to the controling password server or tell the user explicitly which machine to go to in order to change their password.

UPDATE:

The IBM product does look interesting has anyone had experience with Centrify to speak about?

Thoughts?

+1  A: 

If you have more than one UNIX server, you probably want to have one set of passwords and one set of accounts across all of them. Depending on which kind of UNIX this is, you may want to use nis or nis+ or some other native-to-that-UNIX solution to keep passwords centrally managed.

Eddie
2 days later... so much information out there... drowing and reading.
ojblass
+8  A: 

Why not use LDAP since it was designed to do just that and even more?

Adam Hawes
I guess I am an authentication noob but would I be adding a user with his LDAP stored USERID and GROUPID? How does one hook LDAP into the authentication process?
ojblass
With Linux (and anythign that uses PAM) use pam_ldap. Google will point that out.
Adam Hawes
Unfortunately my universe is NCR, SUN, HP, AIX, and Linux. :(
ojblass
All of those should have LDAP compatibility. SUN and HP certainly will. You're in the realm of being able to use vendor support if you're paying for it now.
Adam Hawes
+3  A: 

One option would be to move from telnet to ssh, and use ssh keys instead of passwords. SSH keys tend to change less often than passwords(the user can change the private key's passphrase without touching the remote server), and the public key usually lives in the user's home directory, which you can put on a shared mount (presumably what you already do).

This will make your environment more secure, in addition to solving your synchronization problem. The downside is that the overhead might be slightly higher in setting up each new user, as you need to have them create a key pair and send the public key to an admin who can place it in their home directory for them.

Scotty Allen
The users home directories are on a shared mount. At the whim of an external load balancer where they land for the first authentication is where they enter the domain I control. I cannot make any assumptions about where they are starting from. What you are proposing is a jumbox type solution.
ojblass
You shouldn't have to make any assumptions on where they're starting from. As long as they have accounts on all of the machines that they might end up logging in to, and they're home directories are shared, you should be set.
Scotty Allen
So walk me through this scenario. A new user is setup in our environment. What would have to happen in order for him to be able to just jump onto the machine. Assuming part of the process is to assign him a private key of his own. The target boxes would have to have his public key in his ~/.ssh
ojblass
No, you don't assign him a key (never do that, it's bad form). You ask him to generate a SSH key and give you the public key. You put that in ~user/.ssh/authorized_keys and [s]he can log in using their key-based authentication.
Adam Hawes
Thank you this meets my needs. Enjoy your bounty.
ojblass
Awesome, glad to hear that did the trick.
Scotty Allen
A: 

The LDAP answer was good!

You could try NIS+ from sun. The server/admin piece lives on a Solaris box but it has clients for most *nix boxen. This automagically syncs passwords, userids, groups and access rules over groups of servers.

Another option (but only if your boss has big budget!) is Tivoli Federated Identity Manger from IBM. Which either syncs passwords - or - switches user id and password as you pass between boxes.

James Anderson