Topic: Need Centralized Password Management

[InteXX]

Hello

I'm looking for advice on the best approach for managing domain user passwords centrally on the network.

We're encountering a new need for applications to be able to discover domain user credentials and run under a given user's context, using the concept of Windows impersonation. Further, we don't want to have to maintain multiple password lists. (NEDT—Never Enter Data Twice.)

My first thought is to store them in an encrypted database column, to be decrypted by the application that needs them. Thus an application running on the intranet can provide the necessary user interface for password maintenance and send the relevant updates to SME.

I believe I can make this work, but in order to do so I need to know how to programmatically update domain users' passwords external to SME's native functionality. In essence I need to mimic the activity of SME's password update panel in a PHP page of my own authoring. I'm not as handy at PHP as I am at ASP.NET, but I'm pretty sure I can knock something together.

Where's the best place to find out the internal workings of the password update panel—assuming I've hit upon the best approach—without wading through a stack of books only to find I started studying the wrong architecture?

Any and all ideas are welcome.

Thanks,
Jeff

[Stefano]

if you can, move to SME8b6 and use ldap to auth..

[InteXX]

if you can, move to SME8b6 and use ldap to auth..

I'm curious: What's left to do before SME8 can come out of beta? Is there a work list somewhere?

The business need behind what we need to do doesn't justify the expense of upgrading. In our case at least it could be likened to, say, replacing the foundation because we need to install a woodstove.

But for future reference your suggestion sounds intriguing. Could you elaborate? With LDAP authentication the password store would still be exclusively on SME—how would an application running on a Windows workstation discover a given user's password so it could run under that user's identity?

Thanks,
Jeff

[CharlieBrady]

I'm curious: What's left to do before SME8 can come out of beta? Is there a work list somewhere?

Click on Bugs -> Matrix -> SME Server 8.X and you can see what is not yet resolved or not yet verified.

[InteXX]

Click on Bugs -> Matrix -> SME Server 8.X and you can see what is not yet resolved or not yet verified.

Very good, thank you. I'll try my best to help.

More to the immediate question...  do you know where I should start looking to track down the code that executes behind the SME password update panel? It's that code I need to emulate in the PHP page I'm planning.

Thanks,
Jeff

[InteXX]

Well that turned out to be easier than I was expecting... 

Code: [Select]

#!/usr/bin/perl -w

use esmith::util;
esmith::util::setUserPassword('test.user', 'test-user');
Now all that's left is to shoehorn it into a PHP page.

Can anyone see any problems with this?

Thanks,
Jeff

[CharlieBrady]

Now all that's left is to shoehorn it into a PHP page.

PHP won't be able to execute that code (or similar code). PHP code runs as the 'www' user, whereas server-manager code runs as 'root' via the setuid feature.

[InteXX]

PHP won't be able to execute that code (or similar code).

With this news, then, I've decided to abandon the approach.

Granted I did some investigation first before arriving at this conclusion, but nearly everything I'm finding warns sternly against setting any mechanism or configuration that enables a PHP page to run a process as root.

NEARLY everything, that is...

Here's something called suphp, available at http://www.suphp.org/, but frankly I'm not comfortable enough with Linux admin to want to do much of anything outside of SME's well-prescribed boundaries.

We still need to maintain the external password store, however, so what I'll do is loop through the users, attempting authentication as I go and then displaying a flag for each one that fails. A failure simply means that the admin needs to manually synchronize that user's passwords between the lists.

It's clunky but it'll work.

Thanks,
Jeff

[CharlieBrady]

You can add your own script to the password-modify event directory, which extracts the new hashed password from /etc/shadow and/or /etc/samba/smbpasswd and copies it/sends it anywhere and anyway you like.

[InteXX]

You can add your own script to the password-modify event directory, which extracts the new hashed password from /etc/shadow and/or /etc/samba/smbpasswd and copies it/sends it anywhere and anyway you like.

Hm...

The password would be hashed, though. I wouldn't be able to authenticate with it.

Unles you're seeing something I'm missing.

Thanks,
Jeff