After upgrading to 3.6.1 I am no longer able to login to Debian using my Active Directory account. 'winbind -u', 'winbind -g', 'winbind -t' and many others work fine, but 'winbind -i user' returns 'failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user user'. Changing the verbosity of the logs, I find 'winbindd/winbindd_dual.c:1306 (fork_domain_child) fork_domain_child called without domain.'. The previous wbint_Sid2Uid struct printout shows that dom_name is NULL, but has the correct domain SID. I believe the problem may exist around there. I did upgrade the 'idmap backend = hash' to the new format 'idmap config * : backend = hash' as specifed in the man page without any luck. Name to SID and SID to name works along with user-domgroups, but user-groups does not work. 'wbinifo --group-info=group' fails with a similar error as 'wbinfo -i user'. I bisected the code and the problem was introduced in this commit: commit a9523f17ea2cd85a130e081f3a89cffbee1fdc06 Author: Volker Lendecke <vl@samba.org> Date: Tue Jun 22 15:59:44 2010 +0200 s3: Fix a winbind crash nss_get_info_cached might have invalidated "ads" deep inside. So something in that patch is causing our problem. After inserting some more debug lines in the code, it seems that when it goes looking for a backend, it is having problems. When I compile the idmap backends in statically, it only ever tries to load the template backend and does not use hash as configured. When I compile the backends as shared I get a panic with a backtrace when it tries to load hash.so. I'm going to attach the logs that show the errors at level 10. The first part of the log (22:16) is with shared modules, the second part of the log (22:20) is static modules but the install was not clean and still had the shared modules. I cleaned the install and the third part of the log (22:26) shows the errors with the static modules. If you need me to try anything, let me know. I'll leave the system broken to help with the resolution.
Created attachment 7214 [details] logs with debug level 10 to show the errors.
I get the same wbinfo/getent results as Robert, using 3.6.1 on FreeBSD 8.2.
I've retested on Debian testing with 3.6.3 and my results are still the same as with 3.6.1. Dale
Same thing here on 3.6.2 on FreeBSD 9. The tdb backend works perfectly, but autorid and rid do not work at all.
We just ran into this upgrading winbind from squeeze-backports.
Is there anything more that can be provided? I'm running into issues where winbind 3.5 won't look up a user, but 3.6 does. However we've now run into this rid bug.
Confirming that this bug is still present in Samba 3.6.3. Here I'm using my identity "ITS\ktkaras" in a Windows-2008 domain. Against the comment from "dack", this does not work with the tdb backend. Other than obscuring our corporate SID, the following is verbatim: ktk:~# grep '^[^#]*\(ITS\|idmap\|security\)' /etc/samba/smb.conf workgroup = ITS realm = ITS.CAREGROUP.ORG security = ADS idmap config ITS : backend = tdb idmap config ITS : range = 2000-49999 idmap config * : backend = tdb idmap config * : range = 50000-99999 ktk:~# stop samba stopping samba [ OK ] ktk:~# rm -r /var/cache/samba/* /var/state/samba/* /var/log/samba/* ktk:~# start samba starting samba [ OK ] ktk:~# tdbdump /var/cache/samba/winbindd_cache.tdb | grep -A1 PWINFO ktk:~# getent passwd ktkaras ktk:~# echo $? 2 ktk:~# tdbdump /var/cache/samba/winbindd_cache.tdb | grep -A1 PWINFO key(57) = "NSS/PWINFO/S-1-5-21-91919191-92929292-93939393-12701" data(43) = "\00\00\00\00d\D8X\04\F64aO\00\00\00\00\0B/home/%D/%U\09/bin/bash\FF\FF\FF\FF\FF" ktk:~# wbinfo -n ktkaras S-1-5-21-91919191-92929292-93939393-12701 SID_USER (1) ktk:~# wbinfo -s S-1-5-21-91919191-92929292-93939393-12701 ITS\ktkaras 1 ktk:~# wbinfo -S S-1-5-21-91919191-92929292-93939393-12701 failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND Could not convert sid S-1-5-21-91919191-92929292-93939393-12701 to uid ktk:~# Needless to say, the exact same commands run on a Samba 3.5.13 workstation work like a charm: constellation:~# getent passwd ktkaras ktkaras:*:10000:10004:Karas,Kristofer:/home/ITS/ktkaras:/bin/bash constellation:~# I found a possible smoking gun. Back on the 3.6.3 workstation "ktk", I thought I'd see what ID mappings might exist after issuing the commands seen above. ktk:~# tdbdump /var/state/samba/winbindd_idmap.tdb | grep -A1 'key.*S-1-1-0' key(8) = "S-1-1-0\00" data(10) = "GID 50002\00" ktk:~# Notice that the GID in the output, 50002, falls within the unconfigured "*" range of the "config idmap" portion of the smb.conf file, as noted at top. I would have expected that the GID would be in the 2000-49999 range, as that is what corresponds to the configured domain name "ITS".
I have the same behavior as 3.6.2 on 3.6.3 - tdb back end works, rid doesn't. When I have a chance to set up another test system, I'll check and see if I'm seeing the same gid range issue as Kris. Kris - is it possible there was a different issue affecting your test with the tdb backend? That's working fine on my system with 3.6.3 and this config: [global] workgroup = MYDOMAIN realm = MYDOMAIN.INTRA server string = Storage Server security = ADS dns proxy = No winbind use default domain = Yes winbind enum users = No winbind enum groups = No idmap config * : range = 20000 - 20000000 idmap config * : backend = tdb
Same problem here. Anyone have any recommendations besides just using tdb instead of RID for mapping? Any indication that the Samba team will address this in future 3.6.x releases? Thanks. Mike
Ping from SambaXP, as this bug is apparently assigned to the person just facing me right now..:-)
(In reply to comment #10) > Ping from SambaXP, as this bug is apparently assigned to the person just facing > me right now..:-) Excellent news. If there's any other information needed, just let me know and I'll be happy to help.
confirm this bug on ubuntu 12.04 with samba 3.6.3
(In reply to comment #10) > Ping from SambaXP, as this bug is apparently assigned to the person just facing > me right now..:-) Oops. Pong. :-)
We decided to use idmap_ad along with the tdb for local idmap_ad result storage instead of idmap_rid. It works and makes UID/GID numbers consistent across Linux machines. Hopefully this RID bug will be resolved soon. Mike
Is there missing any input or feedback to fix this bug and get RID backend working again - anything which can be contributed?
I second Torsten's comment. Can the community help in any way to get this fixed? Having one of the major ID-mapping modules broken for so long is a big impediment to Samba's validity for corporate acceptance! Mike
Same bug on samba 3.6.3 on Ubuntu 12.04 x64 From this mail "https://lists.samba.org/archive/samba/2011-August/163799.html" I found an interesting workaround : NOT OK : idmap config MYDOMAIN : backend = rid idmap config MYDOMAIN : range = 5000-10000000 idmap config MYDOMAIN : base_rid = 0 WORKING : idmap config * : backend = rid idmap config * : range = 5000-10000000 idmap config * : base_rid = 0 (and yes I'm pretty sure of MYDOMAIN)
(In reply to comment #17) > Same bug on samba 3.6.3 on Ubuntu 12.04 x64 > From this mail "https://lists.samba.org/archive/samba/2011-August/163799.html" > I found an interesting workaround : > > NOT OK : > idmap config MYDOMAIN : backend = rid > idmap config MYDOMAIN : range = 5000-10000000 > idmap config MYDOMAIN : base_rid = 0 > > WORKING : > idmap config * : backend = rid > idmap config * : range = 5000-10000000 > idmap config * : base_rid = 0 > > (and yes I'm pretty sure of MYDOMAIN) ...it is caused by adding of the default ("*") "idmap config" always when it is not set explicitly. Default one is set to "tdb". Look on testparm output: ... idmap config SMBSETUP : range = 1000 - 2000000000 idmap config SMBSETUP : base_rid = 0 idmap config SMBSETUP : backend = rid idmap config * : backend = tdb ... where appropriate smb.conf lines were: ... ; idmap config * : backend = rid idmap config SMBSETUP : backend = rid ; idmap config * : base_rid = 0 idmap config SMBSETUP : base_rid = 0 ; idmap config * : range = 1000 - 2000000000 idmap config SMBSETUP : range = 1000 - 2000000000 ... - where the "tdb" has "zero rage" allocation set. I also think the issue is inducted by searching of user in "' '-domain" ...where I have found in log.winbindd-idmap the following "strange things": [2012/08/16 20:32:49.578926, 10] winbindd/idmap_util.c:233(idmap_sid_to_gid) idmap_sid_to_gid: sid = [S-1-5-21-2729642224-4200104638-2178513011-513], domain = '' [2012/08/16 20:38:20.029686, 5] winbindd/idmap_rid.c:78(idmap_rid_id_to_sid) Requested id (0) out of range (1000 - 2000000000). Filtered!
...further investigations with rid-backend. Just after the winbindd start: -bash-3.2# id SMBSETUP\\jura uid=2104(SMBSETUP\jura) gid=1513(SMBSETUP\domain users) -bash-3.2# getent passwd SMBSETUP\\jura SMBSETUP\jura:*:2104:1513:jura:/samba/SMBSETUP/jura:/bin/bash -bash-3.2# getent group SMBSETUP\\domain\ users SMBSETUP\domain users:x:1513: -bash-3.2# getent group 1513 SMBSETUP\domain users:x:1513: mkdir /samba/public chown SMBSETUP\\administrator:SMBSETUP\\domain\ users /samba/public/ chmod A0+group:SMBSETUP\\domain\ users:rxpaRc::allow /samba/public/ -bash-3.2# getent group 1513 SMBSETUP\domain users:x:1513: ...so everything is OK yet ...than "kurvitko" is added: -bash-3.2# svcadm enable samba # start smbd -D -bash-3.2# getent group 1513 T4-LDOM10\none:x:1513: ...where T4-LDOM10 is (pre2k) name of the machine (local domain) hash-backend is generating out of range GIDs and even also crashing (*) ...it looks like the Samba bug# 8952 only eliminated the consequences but cause (strange GIDs are generated) remains (*) stack: f9ca9040 sigacthandler (b, 0, ffbfd800, 0, 0, f9d5e1f0) + 58 --- called from signal handler with signal 11 (SIGSEGV) --- fe8a10e8 be_init (0, 18, 803f8c, 6a635e, 8828e8, 8e2e48) + 4 005fbd58 nss_init (884f18, 8857d0, 0, 8dfa40, 858a98, 6a635e) + 3dc 005fc070 find_nss_domain (88b198, 2800, f9d62780, 852000, ff302a40, 255e38) + 1c 005fc254 nss_get_info (88b198, 88e2d8, 88d1a8, 8eb8e0, 8eb8e4, 8eb8dc) + 90 000e1358 nss_get_info_cached (88b198, 88e2d8, 88d1a8, 8eb8e0, 8eb8e4, 8eb8dc) + 144 000f6f60 query_user (88b198, 88d1a8, 88e2d8, 8eb8d8, 8e2a88, ffbfde70) + 618 000d9be8 query_user (88b198, 88d1a8, 88e2d8, 8eb8d8, 853f8c, c0000225) + f4 00101d20 _wbint_QueryUser (ffbfe014, 88c8b0, d9af4, 853e80, 5e10, 88b198) + 3c 0010f458 api_wbint_QueryUser (ffbfe014, 88c8b0, 88c8b4, 8e43f8, 852000, 6bd040) + 13c
Has the bisection of the code not helped locate the problem? I thought taking the time to bisect would help speed up the resolution of the bug. Is there something more that I can do to help with this, short of supplying a patch (this code is too advanced for me)?
anybody found a workaround for this on ubuntu?
Michael - Any updates for us? Over a year is a long time for such a major issue.
I found a working work around (the same as for samba 4.*) You must add a wildcard domain mapping with tdb : idmap config * : backend = tdb idmap config * : range = 2000-4999 # and next your domain config : idmap config MYDOM : backend = rid idmap config MYDOM : range = 5000-10000000 That make sense because you need to have working idmap backend for the BUILTIN and MYHOSTNAME default domains so local users could be mapped. The config is now somehow hardened, I don't know if that's wanted or not but that should be in the docs.
Also: idmap config SMBSETUP : backend = rid idmap config SMBSETUP : range = 100000-199999 idmap config * : backend = autorid idmap config * : range = 200000-4000000000 idmap config * : rangesize = 1000000 ...works for me but use "autorid" for SMBSETUP does not work for me because "autorid" configuration can not be limited to 1 domain only. Thank you for your idea. I was seeking for this (not to use "tdb" because I need consistent id-mapping) for a longer time :-)
(In reply to comment #23) Thomas - a massive thank you for this! That configuration is now working for me on 4.0.5. I haven't tested with 3.x yet, but this is already a huge help.
This workaround also fixed the same problem on 3.6.9-151.el6 (CentOS 6.2) A rather nasty bug to suddenly crop up in a perfectly running installation and rather interesting to hunt down, i must say.
I can confirm that both the work arounds listed in comment #17 and comment #23 do not work on Samba 3.6.3 as distributed with Ubuntu 12.04 64-bit. The symptoms are the same, however: wbinfo -u, wbinfo -g, wbinfo -R <RID>, wbinfo -n <username> work just fine; wbinfo -i <username>, wbinfo -S <SID> return a "WBC_ERR_DOMAIN_NOT_FOUND"
Can you post your smb.conf? I think having a idmap config * entry is a must (and autorid should work then), so any attempt to have smb.conf having only idmap config entries for particular domains (and not the asterisk one) might be doomed to fail. However, we might want to make winbindd complain then and refuse to start instead of giving funny results. Another piece that might cause this to happen is the use of winbind use default domain.. can anyone test out if the problem is related to this parameter?
I can reproduce this on Samba 4.0.7 interestingly, with two different setups one with Ubuntu 12.04 LTS compiled with Debian's experimental deb packages Samba 4.0.7 this requires the hack of * for the idmap config * : backend = tdb Whereas on Ubuntu 13.04 compiled with Debian's experimental deb packages Samba 4.0.7 I don't need to use this hack. Also, using two different AD domains: at home: SH0N.NET at work: XXXX.YYYY.YYYY I wouldn't think that this would make a difference however? I can show logs but will need to filter out company domain information if requested.
(In reply to comment #29) > I can reproduce this on Samba 4.0.7 interestingly, with two different setups > one with Ubuntu 12.04 LTS compiled with Debian's experimental deb packages > Samba 4.0.7 this requires the hack of * for the > > idmap config * : backend = tdb > > > Whereas on Ubuntu 13.04 compiled with Debian's experimental deb packages Samba > 4.0.7 I don't need to use this hack. Also, using two different AD domains: > > at home: SH0N.NET > > at work: XXXX.YYYY.YYYY > > I wouldn't think that this would make a difference however? > > I can show logs but will need to filter out company domain information if > requested. This is my smb.conf: [global] security = ADS realm = DOMAIN.MYCOMPANY.COM password server = * workgroup = DOMAIN winbind separator = / passdb backend = tdbsam idmap uid = 50000-60000 idmap gid = 50000-60000 idmap config * : backend = tdb idmap config * : backend = rid idmap config * : range = 10000-20000 idmap config * : schema_mode = rfc2307 winbind use default domain = yes winbind nss info = rfc2307 winbind enum users = no winbind max clients = 200 winbind enum groups = no socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384 template homedir = /home/%U template shell = /bin/bash preferred master = no local master = no winbind normalize names = yes domain master = no client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes obey pam restrictions = yes winbind offline logon = true winbind refresh tickets = true #kerberos method = secrets and keytab # Don't allow guests restrict anonymous = 2 debug level = 10 log level = 10 One thing still fails oddly: getent passwd / getend group fail if you not specify a *specific* user/group. wbinfo -i, -S, -s, n all work fine
Can someone change the subject and the Samba affected versions? this impacts 3.x and 4.x series and not Debian specific.
I had the same issue on 3.6.6 and found some workarounds by diging out 'winbind -i -d10'. Apparently wbcGetpwnam seems to return WBC_ERR_DOMAIN_NOT_FOUND on several different reasons. #1 LDAP query to AD DC did not return unix id I had in smb.conf: > idmap config DOM : backend = ad and got: > Search for (&(|(sAMAccountType=805306368)(sAMAccountType=805306369)(sAMAccountType=805306370)(sAMAccountType=268435456)(sAMAccountType=536870912))(|(objectSid=\01\05\00\00..snip..\BD\CB\02\00))) in <dc=SUBDOM,dc=DOM,dc=LOCAL> gave 1 replies > Could not get unix ID although the query returns my own record when I throw it from separate LDAP client (Apache Directory Studio, if you are curious). Presumably our LDAP repository does not seem to contain unix related info like UidNumber, GidNumber, etc... I've changed the backend to rid then this issue had gone. > idmap config DOM : backend = rid #2 idmap config range was insufficient I had in smb.conf: > idmap config DOM : range = 100000-199999 and got: > Requested id (283229) out of range (100000 - 199999). Filtered! As the 'requested' id is generated by adding last 6 digits of the sid to the base value of the range (100000 in this example), I should had had full 6 digit range. I changed the range as below then this error had gone: > idmap config DOM : range = 1000000-1999999 Hope this 'requested id out of range' would have mentioned in the /var/log/samba/log.* #3 'winbind separator = _' bug I had in smb.conf: > winbind separator = _ and got: > wbint_LookupName: struct wbint_LookupName > in: struct wbint_LookupName > domain : * > domain : 'DOM' > name : * > name : 'DOM MYNAME' > flags : 0x00000008 (8) and things like this: > wcache_save_name_to_sid: DOM\DOM MYNAME -> S-0-0 (NT_STATUS_NONE_MAPPED) What wrong would be obvious here. I've changed as below (nb: I've avoided '+' as testparm warns about it): > winbind separator = / Now I got wbinfo -i user working. (I have further story till connection from Win7 box actually working, though.)
Any new status on this bug? On SUSE SLES11 I upgraded from SP1 (samba-winbind-3.4.3-1.42.1) to SP2 and even to SP3 (samba-winbind-32bit-3.6.3-0.46.1) and have the same behaviour: With samba-winbind 3.4.3: id zzz uid=12121(zzz) gid=12122 groups=12122 wbinfo -i zzz zzz:*:12121:12122:ZZZ ZZZ. ZZZ:/home/ZZZ:/bin/sh wbinfo -u | wc -l 899 # Lists all users including zzz With samba-winbind 3.6.3: id zzz id: zzz: No such user wbinfo -i zzz failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user zzz wbinfo -u | wc -l 899 # Lists all users including zzz Relevant entries of smb.conf: idmap gid = 10000-20000 idmap uid = 10000-20000 idmap backend = tdb idmap alloc backend = tdb idmap domains = TTT idmap config TTT:default = yes idmap config TTT:schema_mode = rfc2307 idmap config TTT:range = 10000-20000 idmap config TTT:backend = ad winbind separator = + winbind nss info = rfc2307 winbind enum users = yes winbind enum groups = yes winbind refresh tickets = yes winbind use default domain = yes winbind expand groups = 2 winbind nested groups = yes
On 2014-02-19 at 11:42 +0000 samba-bugs@samba.org sent off: > Relevant entries of smb.conf: > idmap gid = 10000-20000 > idmap uid = 10000-20000 > idmap backend = tdb > idmap alloc backend = tdb > idmap domains = TTT > idmap config TTT:default = yes > idmap config TTT:schema_mode = rfc2307 > idmap config TTT:range = 10000-20000 > idmap config TTT:backend = ad this config (like other setups posted in this bug before) are invalid. the (deprecated) idmap gid/uid parameter (for domains which are not defined explicitly) ranges clash with the range of the explicit TTT domain range. I think the release notes contained info about the needed changes of idmap config. I tend to close this bug as worksforme or invalid actually.
I also have this issue on CentOS 6.5 utilizing Samba/Winbind 3.6.9. What information do you need for a proper debug? I can set 'log level = 10' test a couple logins from a working domain as well as from a non-working trusted domain as well. If you give me a list of everything you need, I can get it attached to this bug report properly. I will have to modify some stuff though this is being tested in a live production environment. Mainly Active Directory namings will be changed. -Screwba
You all have seen comment #23 and read the section labeled with 'ID Mapping Changes' at https://wiki.samba.org/index.php/Samba_3.6_Features_added/changed ? I guess that's what Björn intended to point you to with his comment #34. @Screwba: In reply to your comment #35 or to anyone else: > I also have this issue on CentOS 6.5 utilizing Samba/Winbind 3.6.9. Have you tried this approach too? That's why I'm passing it no to state needinfo. Any of those faced by the same trouble should try this approach and report back to us.
(In reply to comment #36) > You all have seen comment #23 and read the section labeled with 'ID Mapping > Changes' at https://wiki.samba.org/index.php/Samba_3.6_Features_added/changed ? > > I guess that's what Björn intended to point you to with his comment #34. > > @Screwba: In reply to your comment #35 or to anyone else: > > > I also have this issue on CentOS 6.5 utilizing Samba/Winbind 3.6.9. > > Have you tried this approach too? That's why I'm passing it no to state > needinfo. > > Any of those faced by the same trouble should try this approach and report back > to us. This is my smb.conf file and as you can see, I do have a * section... [root@cent65-46 ~]# cat /etc/samba/smb.conf [global] server string = vWorkspace Provisioned Linux Host workgroup = DOM1 security = ads realm = dom1.corp domain logons = no template homedir = /home/%D/%U template shell = /bin/bash winbind enum groups = yes winbind enum users = yes winbind use default domain = no domain master = no local master = no prefered master = no os level = 0 log level = 10 idmap config *:backend = tdb idmap config *:range = 11000-20000 idmap config DOM1:backend = rid idmap config DOM1:range = 100000-199000 idmap config DOM2:backend = rid idmap config DOM2:range = 200000-299000
as written before. the configs of this bug report are invalid. Screwba: if you see a similar problem in your setup and if you think you have a valid config and if you see this also in the latest 4.1 release, then please open a new bug report for that. this bug report is being closed.