samba - Mar 2007 - Samba Authentication Using Novell eDirectory via LDAP

Hello,
 
We have a RHEL 4 Update 4 server that was configured to store its 
Samba passwords in eDirectory via LDAP.  This was accomplished by 
adding the following three lines to the [Global] section of smb.conf:

ldap admin dn = cn=admin,o=budget
ldap suffix = o=budget
passdb backend = ldapsam:ldaps://SERVER_NAME:636

After adding the lines and saving the file the admin password is 
stored using smbpasswd -w, the /etc/samba/smbpasswd was renamed to 
old_smbpasswd, and the smb service is started.

This worked as desired, allowing Samba user passwords to be stored in 
the corresponding user's eDirectory user object.  An additional effect, 
although I'm not sure if it was expected or not, is that the password 
can be changed by the Novell Change Password facility available by 
doing a Ctrl+Alt+Del from a user's Windows workstation.  The server 
appears as a available resource, and the password can be changed along 
with changing the Novell password, keeping them in sync.

As we were not ready to permanently effect this change we undid 
everything, removing the three lines and renaming the smbpasswd back to 
its original name.  What is unexpected is that we can now change the 
Samba passwords being stored in /etc/samba/smbpasswd using the same 
Novell Change Password facility.  While that's not necessarily a bad 
thing, I appreciate anyone who can explain why it is working.

What we're stumped by is we've now set up a second RHEL 4 server that 
we believe we've set up identically to the original, and it does store 
the Samba password in eDirectory, but we don't see the server in the 
Novell Change Password facility so that our users can change their own 
Samba passwords.  It's been four months between implementations, and 
while we documented the process, perhaps we forgot something.  Does 
anyone know why this is not working for our second server, or what we 
may have forgotten to do?

Our full smb.conf file follows.  The only thing I would point out is 
we copied the file from the other server, changing only the 
SERVER_NAME, and the name of the first share definition [NEWSAS].  We 
did not change the idmap uid or gid--is that a problem?

[global]
        dns proxy = no
        encrypt passwords = yes
        workgroup = workgroup
        security = user
        idmap uid = 16777216-33554431
        idmap gid = 16777216-33554431
        template shell = /bin/false
        winbind use default domain = no
        ldap admin dn = cn=admin,o=budget
        ldap suffix = o=budget
        passdb backend = ldapsam:ldaps://SERVER_NAME:636
[NEWSAS]
        comment  = new sas server
        path = /
        read only = no
        valid users = sukmcgl
        browseable = yes
        hosts allow = 127.0.0.1 10.57.
        guest ok = no
[homes]
        comment = Home Directories
        valid users = %S
        browseable = no
        guest ok = no
        read only = no

Hello,
 
We have a RHEL 4 Update 4 server that was configured to store its Samba
passwords in eDirectory via LDAP.  This was accomplished by adding the
following three lines to the [Global] section of smb.conf:

ldap admin dn = cn=admin,o=budget
ldap suffix = o=budget
passdb backend = ldapsam:ldaps://SERVER_NAME:636

After adding the lines and saving the file the admin password is stored
using smbpasswd -w, the /etc/samba/smbpasswd was renamed to
old_smbpasswd, and the smb service is started.

This worked as desired, allowing Samba user passwords to be stored in
the corresponding user's eDirectory user object.  An additional effect,
although I'm not sure if it was expected or not, is that the password
can be changed by the Novell Change Password facility available by doing
a Ctrl+Alt+Del from a user's Windows workstation.  The server appears as
a available resource, and the password can be changed along with
changing the Novell password, keeping them in sync.

As we were not ready to permanently effect this change we undid
everything, removing the three lines and renaming the smbpasswd back to
its original name.  What is unexpected is that we can now change the
Samba passwords being stored in /etc/samba/smbpasswd using the same
Novell Change Password facility.  While that's not necessarily a bad
thing, I appreciate anyone who can explain why it is working.

What we're stumped by is we've now set up a second RHEL 4 server that we
believe we've set up identically to the original, and it does store the
Samba password in eDirectory, but we don't see the server in the Novell
Change Password facility so that our users can change their own Samba
passwords.  It's been four months between implementations, and while we
documented the process, perhaps we forgot something.  Does anyone know
why this is not working for our second server, or what we may have
forgotten to do?

Our full smb.conf file follows.  The only thing I would point out is we
copied the file from the other server, changing only the SERVER_NAME,
and the name of the first share definition [NEWSAS].  We did not change
the idmap uid or gid--is that a problem?

[global]
        dns proxy = no
        encrypt passwords = yes
        workgroup = workgroup
        security = user
        idmap uid = 16777216-33554431
        idmap gid = 16777216-33554431
        template shell = /bin/false
        winbind use default domain = no
        ldap admin dn = cn=admin,o=budget
        ldap suffix = o=budget
        passdb backend = ldapsam:ldaps://SERVER_NAME:636
[NEWSAS]
        comment  = new sas server
        path = /
        read only = no
        valid users = sukmcgl
        browseable = yes
        hosts allow = 127.0.0.1 10.57.
        guest ok = no
[homes]
        comment = Home Directories
        valid users = %S
        browseable = no
        guest ok = no
        read only = no
--------------------------------------------------------
This e-mail, including any attachments, may be confidential, privileged or
otherwise legally protected. If you have received this e-mail in error, or from
someone who was not authorized to send it to you, do not disseminate, copy or
otherwise use this e-mail or its attachments. Please notify the sender
immediately if you have received this e-mail by mistake, and delete it from your
system.