Re: [Samba] Winbind behaviour odd in 3.4.9 and 3.5.6 vs 3.2.14 (Samba domain with Samba member servers)
Anyone, I have registered a bug for this, #7763. I am also now suffering from #7066, have followed all the suggestions and have no resolution. Is it the case that Samba in as a domain controller with member server in NT4-style domains should only be used with 3.2.x (which is not ostensibly unsupported)? I find this quite mysterious as surely others are still waiting for Samba 4 to stabilise so they can move to an AD infrastructure. If I am barking up the wrong tree, can anyone point me to any docs that will help me correct my configuration for Samba >=3.4? It seems there is nothing out there that answers my questions, or those that have helpfully replied to my query. To start, can I ask if this simple config that worked in 3.2.x is now unworkable?: idmap backend = ldap:ldap://127.0.0.1 idmap uid = 1-2 idmap gid = 1-2 winbind nested groups = yes winbind trusted domains only = yes winbind use default domain = no winbind enum users = yes winbind enum groups = yes allow trusted domains = yes Thanks Alex -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc Domain House, 5-7 Singer Street, London EC2A 4BQ Tel: (020) 7608 4900 Fax: (020) 7608 1200 (Registered office: as above; Registered in England and Wales under number: 3727592) Authorised and regulated by the Financial Services Authority (entered on the FSA Register; number: 190856) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Winbind behaviour odd in 3.4.9 and 3.5.6 vs 3.2.14 (Samba domain with Samba member servers)
Just reinstalled my webserver, no ssl, so image URL is: http://www.nanogherkin.com/ldap.png -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Winbind behaviour odd in 3.4.9 and 3.5.6 vs 3.2.14 (Samba domain with Samba member servers)
On 26/10/10 17:28, Gaiseric Vandal wrote: I may have indeed forgot to clear the cache files after upgrading from samba 3.0x to 3.4.x. I had various issues with samba servers as member servers - mostly in keeping idmap entries consistent across machines. The solution in the end had been to covert the member servers to BDC's and have ldap backend for everything. Altho I suspect that the "idmap .. backend: nss" may have been an alternate solution. I don't think it was an option for samba 3.0.x and I needed a BDC anyway. I have found the online samba documention on idmap less than optimal. (The man pages are ok tho.) There are ranges set for each trusted domain as well as the "idmap alloc config:range."I am not quite sure if the "idmap alloc config:range" should encompass all the domain ranges or if idmap is supposed to allocate id's from the domain ranges. My experience so far is that new entries are from "idmap alloc config:range." I guess the domain specific ranges are where idmap is supposed to check for existing mappings first? Many thanks GV. I wish there was a newer "By Example" book. If any of the developers are listening, can you help? Ours should be a pretty common setup - two domains, mutually trusting, using NT-style auth and permissions, with Samba member servers? It seems that >= 3.4.0 has made both our configurations outdated (or there is indeed a long-persisting bug). Cheers Alex -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc Domain House, 5-7 Singer Street, London EC2A 4BQ Tel: (020) 7608 4900 Fax: (020) 7608 1200 (Registered office: as above; Registered in England and Wales under number: 3727592) Authorised and regulated by the Financial Services Authority (entered on the FSA Register; number: 190856) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Winbind behaviour odd in 3.4.9 and 3.5.6 vs 3.2.14 (Samba domain with Samba member servers)
I may have indeed forgot to clear the cache files after upgrading from samba 3.0x to 3.4.x. I had various issues with samba servers as member servers - mostly in keeping idmap entries consistent across machines. The solution in the end had been to covert the member servers to BDC's and have ldap backend for everything. Altho I suspect that the "idmap .. backend: nss" may have been an alternate solution. I don't think it was an option for samba 3.0.x and I needed a BDC anyway. I have found the online samba documention on idmap less than optimal. (The man pages are ok tho.) There are ranges set for each trusted domain as well as the "idmap alloc config:range."I am not quite sure if the "idmap alloc config:range" should encompass all the domain ranges or if idmap is supposed to allocate id's from the domain ranges. My experience so far is that new entries are from "idmap alloc config:range." I guess the domain specific ranges are where idmap is supposed to check for existing mappings first? On 10/26/2010 12:02 PM, Alex Crow wrote: On 26/10/10 16:32, Gaiseric Vandal wrote: You may need to specify separate idmap sections for each domain, as well as general settings. Samples of my smb.conf (samba 3.4.x ) are below. When I was on samba 3.0.x, idmap entries would populate for each domain in the correct OU. It would use the general idmap range, not domain specific range (which wasn't a problem.) The problem with samba 3.0.x is that one the idmap cache expired it would not renew.I moved to samba 3.4.x which fixed some issue BUT now stuff does not auto populate. For "trustedomain1" there is only a handful of users, and that almost never changes so manually adding idmap entries (via an ldap editor or wbinfo --allocate-uid / --allocate-gid) was OK. Strange - I have the opposite problem in that I get my Idmap ou populated but also "contaminated" with stuff that should not be there (because it is in the LDAP db and is in the local domain). However to get the population to work at all I had to remove the gencache.tdb and winbind_cache.tdb (and the old idmap_cache.tdb) files before starting samba and winbind. I /do/ get my trusted domain working OK - from what you say you are having to add Idmap entries by hand, which in my situation would be completely impractical (500 accounts in one of the domains - it's a bidirectional trust). Perhaps you could try removing the cache files. I have tried adding this to my config files on a test 3.5.6 domain: idmap config TESTDOM1 : backend = nss idmap config TESTDOM1 : range = 500- Which seems to help stop the entries for accounts already in the LDAP db being put into Idmap, but I am not sure if I should reduce the lower boundary to "0" as I still get entries added for widely known SIDs as soon as a client connects to a share on the member server: dn: sambaSID=S-1-1-0,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10028 sambaSID: S-1-1-0 structuralObjectClass: sambaSidEntry entryUUID: b7a12d38-7565-102f-938a-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026155911Z entryCSN: 20101026155911Z#03#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026155911Z dn: sambaSID=S-1-5-2,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10029 sambaSID: S-1-5-2 structuralObjectClass: sambaSidEntry entryUUID: b7a30e6e-7565-102f-938b-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026155911Z entryCSN: 20101026155911Z#05#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026155911Z And even odder entries like this which do not match any "widely know SIDs": dn: sambaSID=S-1-22-2-0,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10032 sambaSID: S-1-22-2-0 structuralObjectClass: sambaSidEntry entryUUID: f93738b4-7565-102f-938e-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026160101Z entryCSN: 20101026160101Z#01#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026160101Z dn: sambaSID=S-1-22-2-1,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10033 sambaSID: S-1-22-2-1 structuralObjectClass: sambaSidEntry entryUUID: f937bfb4-7565-102f-938f-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026160101Z entryCSN: 20101026160101Z#03#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026160101Z dn: sambaSID=S-1-22-2-2,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10034 sambaSID: S-1-22-2-2 structuralObjectClass: sambaSidEntry entryUUID: f93828d2-7565-102f-9390-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 201010261
Re: [Samba] Winbind behaviour odd in 3.4.9 and 3.5.6 vs 3.2.14 (Samba domain with Samba member servers)
On 26/10/10 16:32, Gaiseric Vandal wrote: You may need to specify separate idmap sections for each domain, as well as general settings. Samples of my smb.conf (samba 3.4.x ) are below. When I was on samba 3.0.x, idmap entries would populate for each domain in the correct OU. It would use the general idmap range, not domain specific range (which wasn't a problem.) The problem with samba 3.0.x is that one the idmap cache expired it would not renew. I moved to samba 3.4.x which fixed some issue BUT now stuff does not auto populate. For "trustedomain1" there is only a handful of users, and that almost never changes so manually adding idmap entries (via an ldap editor or wbinfo --allocate-uid / --allocate-gid) was OK. Strange - I have the opposite problem in that I get my Idmap ou populated but also "contaminated" with stuff that should not be there (because it is in the LDAP db and is in the local domain). However to get the population to work at all I had to remove the gencache.tdb and winbind_cache.tdb (and the old idmap_cache.tdb) files before starting samba and winbind. I /do/ get my trusted domain working OK - from what you say you are having to add Idmap entries by hand, which in my situation would be completely impractical (500 accounts in one of the domains - it's a bidirectional trust). Perhaps you could try removing the cache files. I have tried adding this to my config files on a test 3.5.6 domain: idmap config TESTDOM1 : backend = nss idmap config TESTDOM1 : range = 500- Which seems to help stop the entries for accounts already in the LDAP db being put into Idmap, but I am not sure if I should reduce the lower boundary to "0" as I still get entries added for widely known SIDs as soon as a client connects to a share on the member server: dn: sambaSID=S-1-1-0,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10028 sambaSID: S-1-1-0 structuralObjectClass: sambaSidEntry entryUUID: b7a12d38-7565-102f-938a-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026155911Z entryCSN: 20101026155911Z#03#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026155911Z dn: sambaSID=S-1-5-2,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10029 sambaSID: S-1-5-2 structuralObjectClass: sambaSidEntry entryUUID: b7a30e6e-7565-102f-938b-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026155911Z entryCSN: 20101026155911Z#05#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026155911Z And even odder entries like this which do not match any "widely know SIDs": dn: sambaSID=S-1-22-2-0,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10032 sambaSID: S-1-22-2-0 structuralObjectClass: sambaSidEntry entryUUID: f93738b4-7565-102f-938e-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026160101Z entryCSN: 20101026160101Z#01#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026160101Z dn: sambaSID=S-1-22-2-1,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10033 sambaSID: S-1-22-2-1 structuralObjectClass: sambaSidEntry entryUUID: f937bfb4-7565-102f-938f-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026160101Z entryCSN: 20101026160101Z#03#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026160101Z dn: sambaSID=S-1-22-2-2,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10034 sambaSID: S-1-22-2-2 structuralObjectClass: sambaSidEntry entryUUID: f93828d2-7565-102f-9390-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026160101Z entryCSN: 20101026160101Z#05#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026160101Z dn: sambaSID=S-1-22-2-3,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10035 sambaSID: S-1-22-2-3 structuralObjectClass: sambaSidEntry entryUUID: f9389114-7565-102f-9391-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026160101Z entryCSN: 20101026160101Z#07#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026160101Z dn: sambaSID=S-1-22-2-4,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 10036 sambaSID: S-1-22-2-4 structuralObjectClass: sambaSidEntry entryUUID: f9390388-7565-102f-9392-0b1afbda8e53 creatorsName: cn=Manager,dc=testdom1,dc=net createTimestamp: 20101026160101Z entryCSN: 20101026160101Z#09#00#00 modifiersName: cn=Manager,dc=testdom1,dc=net modifyTimestamp: 20101026160101Z dn: sambaSID=S-1-22-2-6,ou=Idmap,dc=testdom1,dc=net objectClass: sambaIdmapEntry objectClass: sambaSidEn
Re: [Samba] Winbind behaviour odd in 3.4.9 and 3.5.6 vs 3.2.14 (Samba domain with Samba member servers)
You may need to specify separate idmap sections for each domain, as well as general settings. Samples of my smb.conf (samba 3.4.x ) are below. When I was on samba 3.0.x, idmap entries would populate for each domain in the correct OU. It would use the general idmap range, not domain specific range (which wasn't a problem.) The problem with samba 3.0.x is that one the idmap cache expired it would not renew.I moved to samba 3.4.x which fixed some issue BUT now stuff does not auto populate. For "trustedomain1" there is only a handful of users, and that almost never changes so manually adding idmap entries (via an ldap editor or wbinfo --allocate-uid / --allocate-gid) was OK. idmap backend=ldap:ldap://ldap1.domain.com # Next two lines restored to 3.4 - but prob don't need idmap uid = 7-7 idmap gid = 7-7 #IDMAP DEFAULT ALLOC idmap alloc backend = ldap idmap alloc config:ldap_url = ldap://ldap1.domain.com idmap alloc config:ldap_base_dn = ou=alloc,ou=idmap,o=domain.com idmap alloc config:ldap_user_dn = cn=Directory Manager idmap alloc config:range = 3 - 7 idmap config TRUSTEDOMAIN1:backend = ldap idmap config TRUSTEDOMAIN1:readonly = no idmap config TRUSTEDOMAIN1:default=no idmap config TRUSTEDOMAIN1:ldap_base_dn = ou=trustedomain1,ou=idmap,o=domain.com idmap config TRUSTEDOMAIN1:ldap_user_dn = cn=Directory Manager idmap config TRUSTEDOMAIN1:ldap_url = ldap://domain.ssci.com idmap config TRUSTEDOMAIN1:range = 4-45999 idmap config TRUSTEDOMAIN2:backend = ldap idmap config TRUSTEDOMAIN2:readonly = no idmap config TRUSTEDOMAIN2:default=no idmap config TRUSTEDOMAIN2:ldap_base_dn = ou=trustedomain2,ou=idmap,o=domain.com idmap config TRUSTEDOMAIN2:ldap_user_dn = cn=Directory Manager idmap config TRUSTEDOMAIN2:ldap_url = ldap://ldap1.domain.com idmap config TRUSTEDOMAIN2:range = 3-3 My mapped groups (i.e. with both unix id's and well known samba sids) include the following Everyone (S-1-1-0) -> Everyone Creator_Owner (S-1-3-0) -> Creator_Owner Batch Process (S-1-5-3) -> Batch Process Authenticated Users (S-1-5-11) -> Authenticated Users System (S-1-5-18) -> System Network (S-1-5-2) -> Network Interactive (S-1-5-4) -> Interactive Local Service (S-1-5) -> Local Service I don't have everything working 100%. I need dummy unix accounts for users from trustedomain1.Users from trusted domains are authenticating properly with their windows passwords (not the passwords in the dummy accounts.) On 10/26/2010 10:08 AM, Alex Crow wrote: Hi, I have recently upgraded a system with a Samba BDC, PDC and a couple of member servers from 3.2.14 to 3.4.9 (and also tested with 3.5.6). There appears to be some problem with Winbind (we need to run it on all servers as we have a trust relationship to a domain at another office). I have an Idmap range set up in our LDAP database. With 3.2.14, all worked well. The Idmap ou would be populated with, and only with, entries for the accounts on the trusted domain. However, with 3.4.9 and 3.5.6, as soon as a member server is accessed, spurious entries appear in the Idmap ou from the "own domain". In addition, other entries are added for local groups (these are not showing in the screenshot but they are S-1-1-0,S-1-5-11 and S-1-5-2). On another test domain I get entries like I have attached a screenshot from an LDAP client to illustrate the issue. The green box shows the entries I expect (from the trusted domain). The red boxes show entries that have only appeared since the upgrade. I am concerned about this as all the entries for the local domain (dom sid ends 8426) may be causing access control to stop working correctly - I have not seen any hard evidence of this so far, but there have been times we had to restart winbind on the member servers after the initial startup as no-one could access shares on them. The trusted domain is the one ending 4828. Please also note the entry highlighted in red at the bottom. That SID is the one for one of the newly upgraded member servers (plus -513 for Domain Users). Again I don't know why that has been added. Member server smb.conf: [global] unix charset = LOCALE workgroup = CENSORED_domain netbios name = CENSORED_server security = DOMAIN interfaces = eth0, lo passdb backend = ldapsam:ldap://192.168.1.137 username map = /etc/samba/smbusers log level = 1 syslog = 0 log file = /var/log/samba/%m max log size = 1048576 smb ports = 139 445 name resolve order = wins lmhosts bcast hosts time server = no printcap name = CUPS show add printer wizard = Yes enable privileges = yes ldap suffix = dc=censored,dc=net ldap machine suffix = ou=Computers,ou=Accounts ldap user suffix = ou=People,ou=Accounts ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap admin dn = cn=manager,dc=censored,dc=net ldap timeout = 20 idmap backend = ldap:ldap://192.168.1.137 idmap uid = 1-2 idmap gid = 1-2 winbind nested groups = yes winbind trus
Re: [Samba] Winbind behaviour odd in 3.4.9 and 3.5.6 vs 3.2.14 (Samba domain with Samba member servers)
Apologies, forgot the list stripped attachements. Please see: https://www.nanogherkin.com/ldap.png Apologies for self-signed cert. Cheers Alex -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc Domain House, 5-7 Singer Street, London EC2A 4BQ Tel: (020) 7608 4900 Fax: (020) 7608 1200 (Registered office: as above; Registered in England and Wales under number: 3727592) Authorised and regulated by the Financial Services Authority (entered on the FSA Register; number: 190856) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
