I found that with "logon path = \\%L\profiles\%G" in the smb.con file, the root's profile is accessed instead the group's one (%g or %G). In NT with ldapsam_compat says that root.pds can be created; with ldapsam in NT or XP says that the profile is not available. With "logon path = \\%L\profiles\%u" runs well. I tested the groups: exists in /etc/group and don't belongs to group "0"... I added also posixGroups... but the problem remains... also with maps. System tested: Intel, RH 7.x, Kernel 2.4.x, OpenLdap 2.0.27 (runs fine with other early samba versions). some log (the user "111111-1" has gidNumber 201; rot has 0:0). -------------- [2003/07/04 11:46:59, 2] auth/auth.c:check_ntlm_password(301) check_ntlm_password: authentication for user [111111-1] -> [111111-1] -> [111111-1] succeeded [2003/07/04 11:46:59, 3] smbd/password.c:register_vuid(201) User name: 111111-1 Real name: adel cti usuario de prueba [2003/07/04 11:46:59, 3] smbd/password.c:register_vuid(219) UNIX uid 20030 is UNIX user 111111-1, and will be vuid 102 [2003/07/04 11:46:59, 3] smbd/password.c:register_vuid(234) Adding/updating homes service for user '111111-1' using home directory: '/disco1/111111-1/' [2003/07/04 11:46:59, 3] smbd/process.c:process_smb(882) Transaction 35 of length 90 [2003/07/04 11:46:59, 3] smbd/process.c:switch_message(676) switch message SMBtrans2 (pid 23018) [2003/07/04 11:46:59, 3] lib/util_seaccess.c:se_access_check(267) [2003/07/04 11:46:59, 3] lib/util_seaccess.c:se_access_check(268) se_access_check: user sid is S-1-5-21-2715378125-3642892448-1277082696-41060 se_access_check: also S-1-5-21-2715378125-3642892448-1277082696-1405 se_access_check: also S-1-1-0 se_access_check: also S-1-5-2 se_access_check: also S-1-5-11 [2003/07/04 11:46:59, 3] smbd/sec_ctx.c:set_sec_ctx(287) setting sec ctx (20030, 202) - sec_ctx_stack_ndx = 0 [2003/07/04 11:46:59, 3] smbd/trans2.c:call_trans2qfilepathinfo(1830) call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 257 [2003/07/04 11:46:59, 3] lib/util.c:unix_clean_name(580) unix_clean_name [/root] [2003/07/04 11:46:59, 3] lib/util.c:unix_clean_name(580) unix_clean_name [root] [2003/07/04 11:46:59, 3] smbd/trans2.c:call_trans2qfilepathinfo(1860) call_trans2qfilepathinfo root level=257 call=5 total_data=0 [2003/07/04 11:46:59, 3] smbd/process.c:process_smb(882) Transaction 36 of length 92 [2003/07/04 11:46:59, 3] smbd/process.c:switch_message(676) switch message SMBchkpth (pid 23018) [2003/07/04 11:46:59, 3] lib/util.c:unix_clean_name(580) unix_clean_name [/root/Configuraci¢n local]
Was this against a post 3.0.0beta2 cvs snapshot? There was a bug introduced for a short time where the uid of all users was being set to 0 on a domain logon. If this was against beta2, can you retest using the latest CVS code since this has changed a lot and think is working ok now.
Tested and runs OK with the one of the saturday's CVS. Thanks a lot
verified by reporter
Again fails with the beta3. I don't have any map definied in this test. The log is more or less the same as posted initially, but i don't know if this new piece about mapping is related (and the ldap runs fine, have permisions, and the user binds correctly): [2003/07/17 11:58:26, 2] passdb/pdb_ldap.c:ldapsam_search_one_group(1619) ldapsam_search_one_group: searching for:[(&(objectClass=sambaGroupMapping)(gidNumber=202))] [2003/07/17 11:58:26, 0] lib/smbldap.c:smbldap_open(799) smbldap_open: cannot access LDAP when not root.. [2003/07/17 11:58:26, 1] lib/smbldap.c:smbldap_retry_open(888) Connection to LDAP Server failed for the 1 try! [2003/07/17 11:58:26, 0] passdb/pdb_ldap.c:ldapsam_search_one_group(1632) ldapsam_search_one_group: Problem during the LDAP search: LDAP error: (Insufficient access)ldapsam_search_one_group: Query was: o=smb, dc=unav, dc=es, (&(objectClass=sambaGroupMapping)(gidNumber=202)) [2003/07/17 11:58:26, 3] smbd/uid.c:fetch_sid_from_gid_cache(650) fetch sid from gid cache 202 -> S-1-5-21-2715378125-3642892448-1277082696-1405 [2003/07/17 11:58:26, 3] auth/auth.c:check_ntlm_password(264) check_ntlm_password: sam authentication for user [111111-1] succeeded
make sure to reopen bugs. Closed ones get ignored.
reproduced against latest CVS.
problem is that the profile file substitution is being performed for the user's groups have been initialized so the group '0' is used. See init_sam_from_ldap() and _api_net_sam_logon()
Adding comments from BUG 264 if in the smb.conf the profile path is setting to "\\%L\profiles\%g the profiles from "root" are readed *instead* the users'one. Assume that the uidNumber is 20038 ("999999-9") and the groupNumber is 202 ("prn1") and the server name is bilbo (%L). in the routine init_sam_from_ldap() a extra debug at pdb_set_profile_path like: DEBUG(0, ("init_sam_from_ldap: %s, %s, %d, %d\n",lp_logon_path(), profile_path, uid, gid)); shows in the log: [2003/08/02 20:59:59, 0] passdb/pdb_ldap.c:init_sam_from_ldap(664) init_sam_from_ldap: \\%L\profiles\%g, , -1, 0 so the group is 0 (root) and the uid is -1 instead 20038 and in passdb/pdb_get_set.c| pdb_set_profile_path() routine, the log says: [2003/08/02 20:59:59, 10] passdb/pdb_get_set.c:pdb_set_profile_path(720) pdb_set_profile_path: setting profile path \\bilbo\profiles\root when *must* be "\\bilbo\profiles\prn2"
*** Bug 264 has been marked as a duplicate of this bug. ***
should be fixed in SAMBA_3_0 cvs tree. Had to call getpwnam() when initializing the SAM_ACCOUNT structure from LDAP so that we used the correct group.
I tested the new code and fix the error perfectly. I tested from NT and XP ws, with ldapsam, groupmap and so. Thanks a lot!
originally reported against 3.0.0beta3. CLeaning out non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.