When an XP station joins a Samba3 beta3 PDC using LDAP backend, it has to join the domain two times in succession to succeed. The first join always encounters "Access Denied" problem though the entry for the workstation is added (during the first join domain action). The following extract of smbd.log shows the sequence of the first failure. [2003/07/18 12:20:53, 5] lib/username.c:Get_Pwnam(288) Finding user vaio$ [2003/07/18 12:20:53, 5] lib/username.c:Get_Pwnam_internals(223) Trying _Get_Pwnam(), username as lowercase is vaio$ [2003/07/18 12:20:53, 5] lib/username.c:Get_Pwnam_internals(239) Trying _Get_Pwnam(), username as uppercase is VAIO$ [2003/07/18 12:20:54, 5] lib/username.c:Get_Pwnam_internals(247) Checking combinations of 0 uppercase letters in vaio$ [2003/07/18 12:20:54, 5] lib/username.c:Get_Pwnam_internals(251) Get_Pwnam_internals didn't find user [vaio$]! [2003/07/18 12:20:56, 3] rpc_server/srv_samr_nt.c:_api_samr_create_user(2304) _api_samr_create_user: Running the command `/home/samba-3.0.0beta3/scripts/add-machine vaio$' gave 0 [2003/07/18 12:20:56, 5] lib/username.c:Get_Pwnam(288) Finding user vaio$ [2003/07/18 12:20:56, 5] lib/username.c:Get_Pwnam_internals(223) Trying _Get_Pwnam(), username as lowercase is vaio$ [2003/07/18 12:20:56, 5] lib/username.c:Get_Pwnam_internals(251) Get_Pwnam_internals did find user [vaio$]! [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_username(585) pdb_set_username: setting username vaio$, was [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_init_flags(485) element 11 -> now SET [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_fullname(666) pdb_set_full_name: setting full name vaio$, was [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_init_flags(485) element 12 -> now SET [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_unix_homedir(801) pdb_set_unix_homedir: setting home dir /dev/null, was NULL [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_init_flags(485) element 21 -> now SET [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_domain(612) pdb_set_domain: setting domain HKLAG, was [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_user_sid(512) pdb_set_user_sid: setting user sid S-1-5-21-4221261723-3157684092-2694793244-21002 [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_init_flags(485) element 17 -> now SET [2003/07/18 12:20:56, 10] passdb/pdb_compat.c:pdb_set_user_sid_from_rid(73) pdb_set_user_sid_from_rid: setting user sid S-1-5-21-4221261723-3157684092-2694793244-21002 from rid 21002 [2003/07/18 12:20:56, 2] passdb/pdb_ldap.c:ldapsam_search_one_group(1619) ldapsam_search_one_group: searching for:[(&(objectClass=sambaGroupMapping)(gidNumber=553))] [2003/07/18 12:20:56, 4] passdb/pdb_ldap.c:ldapsam_getgroup(1770) Did not find group [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_group_sid(548) pdb_set_group_sid: setting group sid S-1-5-21-4221261723-3157684092-2694793244-2107 [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_init_flags(485) element 18 -> now SET [2003/07/18 12:20:56, 10] passdb/pdb_compat.c:pdb_set_group_sid_from_rid(100) pdb_set_group_sid_from_rid: setting group sid S-1-5-21-4221261723-3157684092-2694793244-2107 from rid 2107 [2003/07/18 12:20:56, 10] passdb/passdb.c:pdb_init_sam_new(315) pdb_init_sam_new: no RID specified. Generating one via old algorithm [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_user_sid(512) pdb_set_user_sid: setting user sid S-1-5-21-4221261723-3157684092-2694793244-21002 [2003/07/18 12:20:56, 10] passdb/pdb_get_set.c:pdb_set_init_flags(485) element 17 -> now SET [2003/07/18 12:20:56, 10] passdb/pdb_compat.c:pdb_set_user_sid_from_rid(73) pdb_set_user_sid_from_rid: setting user sid S-1-5-21-4221261723-3157684092-2694793244-21002 from rid 21002 [2003/07/18 12:20:56, 2] lib/smbldap.c:smbldap_search_suffix(1056) smbldap_search_suffix: searching for:[(&(uid=vaio$)(objectclass=sambaSamAccount))] [2003/07/18 12:20:56, 0] passdb/pdb_ldap.c:ldapsam_add_sam_account(1458) User 'vaio$' already in the base, with samba attributes [2003/07/18 12:20:56, 0] rpc_server/srv_samr_nt.c:_api_samr_create_user(2326) could not add user/computer vaio$ to passdb. Check permissions? The problem does not exist in samba2.2.8a (same function as PDC with LDAP)
I *think* I've been able to reproduce this once, now I don't get it anymore. Could you tell me the *exact* steps how to reproduce this with latest 3_0 CVS? Thanks, Volker
I did it simply by firstly backing up my ldap database, then wiped out clean the ldap database, then populate new base entries (root, administrator, nobody, and groups). Then restarted ldap server and samba server - (I did not touch any of the tdb files, this may cause the problem, but let's assume it is not needed) - and then I have the XP workstation joins the domain. The first join will have "access denied", and a subsequent join that follows immediately is successful. I also tried to completely remove the samba installation (ie. remove every bit of samba stuff), and then completely reinstall samba and perform the above ldap data reinitialization, and the same symptom of having to join twice to work still happens. If as Volker said it happened *once* and not again it might have been because the TDB files (connection? session?) are not initialized with "first" XP workstation so the first join of the first workstation always fails. I have not verified if a joining of a second (or more) workstation will *not* need two joins. I may do so today. Still if it works for the second (onwards) workstation join the failure of the first workstation join (ie. the first workstation needing two joins to work) still looks like a problem.
I used another machine (newly built XP workstation) to join the domain (with one machine already joined the domain, and up and running). It still failed the first time (access denied, with the same "passdb ... Check permissions?" error. Again a second join immediately followed the first one succeeded. So at least it does not seem to be tdb problems I presume.
Can you make sure that the LDAP searches logged in log.smbd can actually be run ? I remember seeing this when the indexes on the OpenLDAP server were corrupted. Run slapingdex on the server try again if you don't mind.
closing this one since I'm pretty sure this is an OpenLDAP bug with indexing.
originally reported against 3.0.0beta2. CLeaning out non-production release versions.
database cleanup