[CentOS] How best to allow users to change Samba passwords?

Mon Jul 6 13:35:03 UTC 2009
Kevin Thorpe <kevin at pibenchmark.com>

I know this is a late reply, but I've only just got round to things. 
pgina works absolutely fine, thanks for that. It also allows fallback to 
local users for our laptop wielding brethren.
All I need to do now is work out how to use the Centos/redhat/fedora 
directory server.

On 01/07/2009 16:38, Alexander Georgiev wrote:
> 2009/7/1 Kevin Thorpe<kevin at pibenchmark.com>:
>> On 01/07/2009 14:29, Jason Pyeron wrote:
>> We're missing some bits on this. We don't run Windows servers at all so the
>> Exchange route is out. Also most of our
>> workstations are only windows Home, not Professional so we can't use a
>> domain or the ctrl-alt-del approach. I think
>> I'm going to have to use openLDAP to do this, but it seems overly hard to
>> set up. It will however work for Samba,
>> Scalix and our website (Drupal) so I think it's the way to go.
> I have successfully used http://www.pgina.org to authenticate Windows
> Home users against a Samba domain. Pgina has plugins for different
> authentication providers, so openLDAP should work.
> Of course you should ensure user and password synchronization between
> the 2 servers as a first step. OpenLDAP will work. I have used
> http://sourceforge.net/projects/smbldap-tools/ to store samba account
> database in openldap.
> The real challenge for me 7 years ago, was password expiration. I
> believe this requirement will sooner or later come to you. Users tend
> to use the same password for years. Therefore a mechanism of password
> expiration must be enforced to make sure those passwords will be
> changed, also the mechanism observes that passwords are strong and not
> rotated.
> When I was using a Windows NT4 domain there was a mechanism which
> would observe the password expiration of domain users and would
> trigger via RPC a password change request on the user workstation.
> Upon login, the user would not be granted login until the password is
> changed.
> I could not reproduce this behavior using samba 2.2.xxx and have not
> tried since then.