More LDAP info

Dana Canfield canfield at uindy.edu
Thu Oct 4 13:52:04 GMT 2001


Jerry,

Attached is the patch to make pdb_ldap fall back to lp_* if the
attributes aren't found in LDAP.  It's trivial, but at least it's tested
and seems to do what it's supposed to.  Obviously you can yank out the
DEBUG lines, or kick them up to a higher level if you like.

There still seem to be a couple of minor issues with LDAP, though:

1) Although %m is expanded properly in these parameters, %u is expanded
to nobody.  This seems to happen regardless of whether the parameter is
defined in LDAP or is fallen through to the config file.  I'm guessing
that the LDAP username doesn't get passed to the right places until
after the ldap backend does it's expansion, so it's defaulting to
nobody.  I tried moving all the username related stuff in pdb_ldap up
before the scriptPath related stuff, and although it compiled, it didn't
help.  Again, all of this gets above my head pretty quick, but I'm
trying. ;-)

2) If an attribute is not defined in LDAP when a user logs in, it ends
up being set somewhere along the line by the time they log out.  For
example, we don't define a scriptPath in LDAP for our users because we
want machine-specific batch files to execute, based on what lab they are
in, so we use a %m.bat line in smb.conf.  Now, the scriptPath is being
set to the machine-name.bat of whatever machine they first log into. 
Even worse, the homeDirectory attribute is being updated in ldap to
point to the value of smbHome.

I can't think of any time when it would be a good idea for samba to
automatically update somebody's scriptPath, smbHome, and especially the
homeDirectory.

3) The pwdMustChange works properly in the LDAP backend, and if it's not
defined, the user gets a warning that their password must be changed. 
That makes it inconsistent with the was the smbpasswd backend works
(which appears to hard-wire an expiration about a week in the future). 
I figured you were already aware of that, though.  

I hope this info is helpful.  The biggest issue right now appears to be
#2, as it actually breaks posix accounts that are stored in LDAP.  Other
than these, having everything in LDAP is great.  Let me know if there's
something more I can do to help chase these down.


-------------- next part --------------
--- samba-2.2.2/source/passdb/pdb_ldap.c	Tue Oct  2 19:36:04 2001
+++ pdb_ldap.c.new	Tue Oct  2 20:54:55 2001
@@ -411,12 +411,35 @@
 	}
 
 	get_single_attribute(ldap_struct, entry, "homeDrive", dir_drive);
+	DEBUG(0,("homeDrive is set to %s\n",dir_drive));
+	if (!*dir_drive) {
+		pstrcpy(dir_drive, lp_logon_drive());
+		DEBUG(0,("homeDrive fell back to %s\n",dir_drive));
+	}
+
 	get_single_attribute(ldap_struct, entry, "smbHome", homedir);
+	DEBUG(0,("smbHome is set to %s\n",homedir));
+	if (!*homedir) {
+		pstrcpy(homedir, lp_logon_home());
+		DEBUG(0,("smbHome fell back to %s\n",homedir));
+	}
+
 	get_single_attribute(ldap_struct, entry, "scriptPath", logon_script);
+	DEBUG(0,("scriptPath is set to %s\n",logon_script));
+	if (!*logon_script) {
+		pstrcpy(logon_script, lp_logon_script());
+		DEBUG(0,("scriptPath fell back to %s\n",logon_script));
+	}
+
 	get_single_attribute(ldap_struct, entry, "profilePath", profile_path);
+	DEBUG(0,("profilePath is set to %s\n",profile_path));
+	if (!*profile_path) {
+		pstrcpy(profile_path, lp_logon_path());
+		DEBUG(0,("profilePath fell back to %s\n",profile_path));
+	}
+
 	get_single_attribute(ldap_struct, entry, "description", acct_desc);
 	get_single_attribute(ldap_struct, entry, "userWorkstations", workstations);
-
 	get_single_attribute(ldap_struct, entry, "rid", temp);
 	user_rid = (uint32)strtol(temp, NULL, 16);
 	get_single_attribute(ldap_struct, entry, "primaryGroupID", temp);


More information about the samba-technical mailing list