Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
On 16 May 2012 16:50, Javier Conti javier.co...@gmail.com wrote: On 16 May 2012 13:19, Michael Adam ob...@samba.org wrote: Hi Javier, Javier Conti wrote: On 15 May 2012 23:29, Michael Adam ob...@samba.org wrote: Hi Javier, Javier Conti wrote: Dear list, upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. Although I tried many changes to the config, according to some hints found on the web, this is what I was using with Samba 3.4.3: [global] workgroup = MYDOMAIN realm = MYREALM security = ADS idmap backend = idmap_ad idmap uid = 64000 - 64999 idmap gid = 64000 - 64999 idmap config MYDOMAIN : default = yes idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema_mode = rfc2307 winbind use default domain = yes winbind nss info = rfc2307 winbind offline logon = yes winbind refresh tickets = yes [...] Any hints on what has changed with Samba 3.6.3 and/or what to change to adapt the configuration to 3.6.3 (if necessary)? Some comments: The above config makes no real sense for me, neither for 3.4 nor for 3.6: * The parameter idmap config DOMAIN : default = yes/no has been removed in samba 3.3. It only existed from 3.0.25 to 3.2. (http://www.samba.org/samba/history/samba-3.3.0.html) * You are using the backend ad (or idmap_ad which is a deprecated synonym) both in idmap config MYDOMAIN : backend and in idmap backend. Both with different ranges. This does not seem to make sense to me. It is necessary to specify a writable backend for the catch all default idmap configuration, e.g. tdb or ldap. In 3.6, the idmap backend has been replaced by idmap config * : backend, etc. A valid config for 3.4 would be: ~ [global] workgroup = MYDOMAIN idmap backend = tdb idmap uid = x-y idmap gid = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ The corresponding for 3.6: ~ [global] workgroup = MYDOMAIN idmap config * : backend = tdb idmap config * : range = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ Hi Michael, thanks for your input. The latter is indeed the configuration I'm running lately. Ok, so you _are_ running the default domain with the tdb idmap backend. -- Good. Could you please check with the more low level wbinfo commands the results of the commands for id mapping: wbinfo -S S-1-5-21-828208052-1092558876-1846952604-22794 == should give a uid That works and gives me 10106. wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-22794 == should fail That fails with WBC_ERR_DOMAIN_NOT_FOUND. wbinfo -S S-1-5-21-828208052-1092558876-1846952604-513 == should fail That fails with WBC_ERR_DOMAIN_NOT_FOUND. wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-513 == should give a gid That fails with WBC_ERR_DOMAIN_NOT_FOUND. Ok, the error messages seem to be bogus. But from what you have written below, the behaviour is correct. I don't know if it's related to that, but in the RFC2307 fields of the 10106 user I put as primary group 1, which is not Domain Users, but S-1-5-21-828208052-1092558876-1846952604-51 is actually Domain Users. The group Domain Users has no RFC2307 gid attribute. We didn't populate it since it's not used at all in the Unix environment. Ah! That explains the above results. If I get the SID of the user primary group (i.e. the one I see using id(1) on a 3.4.3 client) and then perform a sid-to-gid (wbinfo -Y) it works. If you don't have a gid associated to the domain users group in AD, but you configured the idmap backend ad for this domain, then you should get no gid for this group out of winbindd: If the older version 3.4 falls back to allocating one from the default range, then this is a bug in 3.4, and 3.6 is correct. In 3.4 I don't have a gid for Domain Users. This has never been a problem since the Domain Users group is not used at all on Unix machines. If I perform a getent(1) on group Domain Users I get nothing, if I perform a
Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
On 15 May 2012 23:29, Michael Adam ob...@samba.org wrote: Hi Javier, Javier Conti wrote: Dear list, upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. Although I tried many changes to the config, according to some hints found on the web, this is what I was using with Samba 3.4.3: [global] workgroup = MYDOMAIN realm = MYREALM security = ADS idmap backend = idmap_ad idmap uid = 64000 - 64999 idmap gid = 64000 - 64999 idmap config MYDOMAIN : default = yes idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema_mode = rfc2307 winbind use default domain = yes winbind nss info = rfc2307 winbind offline logon = yes winbind refresh tickets = yes [...] Any hints on what has changed with Samba 3.6.3 and/or what to change to adapt the configuration to 3.6.3 (if necessary)? Some comments: The above config makes no real sense for me, neither for 3.4 nor for 3.6: * The parameter idmap config DOMAIN : default = yes/no has been removed in samba 3.3. It only existed from 3.0.25 to 3.2. (http://www.samba.org/samba/history/samba-3.3.0.html) * You are using the backend ad (or idmap_ad which is a deprecated synonym) both in idmap config MYDOMAIN : backend and in idmap backend. Both with different ranges. This does not seem to make sense to me. It is necessary to specify a writable backend for the catch all default idmap configuration, e.g. tdb or ldap. In 3.6, the idmap backend has been replaced by idmap config * : backend, etc. A valid config for 3.4 would be: ~ [global] workgroup = MYDOMAIN idmap backend = tdb idmap uid = x-y idmap gid = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ The corresponding for 3.6: ~ [global] workgroup = MYDOMAIN idmap config * : backend = tdb idmap config * : range = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ Hi Michael, thanks for your input. The latter is indeed the configuration I'm running lately. I checked everything (I know) from the Samba point of view, and it almost seems ok, but wbinfo -i fails as follows: # wbinfo -i myuser failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user myuser Using the same user, for example, I can do: # wbinfo -n myuser S-1-5-21-828208052-1092558876-1846952604-22794 SID_USER (1) # wbinfo -n Domain Users S-1-5-21-828208052-1092558876-1846952604-513 SID_DOM_GROUP (2) # wbinfo -s S-1-5-21-828208052-1092558876-1846952604-22794 MYDOMAIN\myuser 1 # wbinfo -s S-1-5-21-828208052-1092558876-1846952604-513 MYDOMAIN\Domain Users # net -Uadminuser user info myuser |head Enter adminuser's password: domain users [...] # net -Uadminuser ads user |grep myuser Enter adminuser's password: myuser Obviously, id(1) and getent(1) fail. What I get is: [2012/05/14 16:50:47.958484, 6] winbindd/winbindd.c:792(new_connection) accepted socket 25 [2012/05/14 16:50:47.958604, 10] winbindd/winbindd.c:642(process_request) process_request: request fn INTERFACE_VERSION [2012/05/14 16:50:47.958644, 3] winbindd/winbindd_misc.c:384(winbindd_interface_version) [ 5756]: request interface version [2012/05/14 16:50:47.958705, 10] winbindd/winbindd.c:738(winbind_client_response_written) winbind_client_response_written[5756:INTERFACE_VERSION]: delivered response to client [2012/05/14 16:50:47.958771, 10] winbindd/winbindd.c:642(process_request) process_request: request fn WINBINDD_PRIV_PIPE_DIR [2012/05/14 16:50:47.958808, 3] winbindd/winbindd_misc.c:417(winbindd_priv_pipe_dir) [ 5756]: request location of privileged pipe [2012/05/14 16:50:47.958870, 10] winbindd/winbindd.c:738(winbind_client_response_written) winbind_client_response_written[5756:WINBINDD_PRIV_PIPE_DIR]: delivered response to client [2012/05/14 16:50:47.958939, 6] winbindd/winbindd.c:792(new_connection) accepted socket 26 [2012/05/14 16:50:47.958995, 6] winbindd/winbindd.c:840(winbind_client_request_read) closing socket 25, client exited [2012/05/14 16:50:47.959058, 10]
Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
Hi Javier, Javier Conti wrote: On 15 May 2012 23:29, Michael Adam ob...@samba.org wrote: Hi Javier, Javier Conti wrote: Dear list, upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. Although I tried many changes to the config, according to some hints found on the web, this is what I was using with Samba 3.4.3: [global] workgroup = MYDOMAIN realm = MYREALM security = ADS idmap backend = idmap_ad idmap uid = 64000 - 64999 idmap gid = 64000 - 64999 idmap config MYDOMAIN : default = yes idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema_mode = rfc2307 winbind use default domain = yes winbind nss info = rfc2307 winbind offline logon = yes winbind refresh tickets = yes [...] Any hints on what has changed with Samba 3.6.3 and/or what to change to adapt the configuration to 3.6.3 (if necessary)? Some comments: The above config makes no real sense for me, neither for 3.4 nor for 3.6: * The parameter idmap config DOMAIN : default = yes/no has been removed in samba 3.3. It only existed from 3.0.25 to 3.2. (http://www.samba.org/samba/history/samba-3.3.0.html) * You are using the backend ad (or idmap_ad which is a deprecated synonym) both in idmap config MYDOMAIN : backend and in idmap backend. Both with different ranges. This does not seem to make sense to me. It is necessary to specify a writable backend for the catch all default idmap configuration, e.g. tdb or ldap. In 3.6, the idmap backend has been replaced by idmap config * : backend, etc. A valid config for 3.4 would be: ~ [global] workgroup = MYDOMAIN idmap backend = tdb idmap uid = x-y idmap gid = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ The corresponding for 3.6: ~ [global] workgroup = MYDOMAIN idmap config * : backend = tdb idmap config * : range = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ Hi Michael, thanks for your input. The latter is indeed the configuration I'm running lately. Ok, so you _are_ running the default domain with the tdb idmap backend. -- Good. Could you please check with the more low level wbinfo commands the results of the commands for id mapping: wbinfo -S S-1-5-21-828208052-1092558876-1846952604-22794 == should give a uid That works and gives me 10106. wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-22794 == should fail That fails with WBC_ERR_DOMAIN_NOT_FOUND. wbinfo -S S-1-5-21-828208052-1092558876-1846952604-513 == should fail That fails with WBC_ERR_DOMAIN_NOT_FOUND. wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-513 == should give a gid That fails with WBC_ERR_DOMAIN_NOT_FOUND. Ok, the error messages seem to be bogus. But from what you have written below, the behaviour is correct. I don't know if it's related to that, but in the RFC2307 fields of the 10106 user I put as primary group 1, which is not Domain Users, but S-1-5-21-828208052-1092558876-1846952604-51 is actually Domain Users. The group Domain Users has no RFC2307 gid attribute. We didn't populate it since it's not used at all in the Unix environment. Ah! That explains the above results. If I get the SID of the user primary group (i.e. the one I see using id(1) on a 3.4.3 client) and then perform a sid-to-gid (wbinfo -Y) it works. If you don't have a gid associated to the domain users group in AD, but you configured the idmap backend ad for this domain, then you should get no gid for this group out of winbindd: If the older version 3.4 falls back to allocating one from the default range, then this is a bug in 3.4, and 3.6 is correct. The other thing is what is to be done with the primary gid field from the ad unix schema extensions, can be a bug in samba. I am personally not certain that it is a good idea to use this at all. I'd rather suggest to use the primary group sid and give it a mapping. Then you have the same view under windows and under linux/samba. To be perfectly clear:
Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
On 16 May 2012 13:19, Michael Adam ob...@samba.org wrote: Hi Javier, Javier Conti wrote: On 15 May 2012 23:29, Michael Adam ob...@samba.org wrote: Hi Javier, Javier Conti wrote: Dear list, upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. Although I tried many changes to the config, according to some hints found on the web, this is what I was using with Samba 3.4.3: [global] workgroup = MYDOMAIN realm = MYREALM security = ADS idmap backend = idmap_ad idmap uid = 64000 - 64999 idmap gid = 64000 - 64999 idmap config MYDOMAIN : default = yes idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema_mode = rfc2307 winbind use default domain = yes winbind nss info = rfc2307 winbind offline logon = yes winbind refresh tickets = yes [...] Any hints on what has changed with Samba 3.6.3 and/or what to change to adapt the configuration to 3.6.3 (if necessary)? Some comments: The above config makes no real sense for me, neither for 3.4 nor for 3.6: * The parameter idmap config DOMAIN : default = yes/no has been removed in samba 3.3. It only existed from 3.0.25 to 3.2. (http://www.samba.org/samba/history/samba-3.3.0.html) * You are using the backend ad (or idmap_ad which is a deprecated synonym) both in idmap config MYDOMAIN : backend and in idmap backend. Both with different ranges. This does not seem to make sense to me. It is necessary to specify a writable backend for the catch all default idmap configuration, e.g. tdb or ldap. In 3.6, the idmap backend has been replaced by idmap config * : backend, etc. A valid config for 3.4 would be: ~ [global] workgroup = MYDOMAIN idmap backend = tdb idmap uid = x-y idmap gid = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ The corresponding for 3.6: ~ [global] workgroup = MYDOMAIN idmap config * : backend = tdb idmap config * : range = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ Hi Michael, thanks for your input. The latter is indeed the configuration I'm running lately. Ok, so you _are_ running the default domain with the tdb idmap backend. -- Good. Could you please check with the more low level wbinfo commands the results of the commands for id mapping: wbinfo -S S-1-5-21-828208052-1092558876-1846952604-22794 == should give a uid That works and gives me 10106. wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-22794 == should fail That fails with WBC_ERR_DOMAIN_NOT_FOUND. wbinfo -S S-1-5-21-828208052-1092558876-1846952604-513 == should fail That fails with WBC_ERR_DOMAIN_NOT_FOUND. wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-513 == should give a gid That fails with WBC_ERR_DOMAIN_NOT_FOUND. Ok, the error messages seem to be bogus. But from what you have written below, the behaviour is correct. I don't know if it's related to that, but in the RFC2307 fields of the 10106 user I put as primary group 1, which is not Domain Users, but S-1-5-21-828208052-1092558876-1846952604-51 is actually Domain Users. The group Domain Users has no RFC2307 gid attribute. We didn't populate it since it's not used at all in the Unix environment. Ah! That explains the above results. If I get the SID of the user primary group (i.e. the one I see using id(1) on a 3.4.3 client) and then perform a sid-to-gid (wbinfo -Y) it works. If you don't have a gid associated to the domain users group in AD, but you configured the idmap backend ad for this domain, then you should get no gid for this group out of winbindd: If the older version 3.4 falls back to allocating one from the default range, then this is a bug in 3.4, and 3.6 is correct. In 3.4 I don't have a gid for Domain Users. This has never been a problem since the Domain Users group is not used at all on Unix machines. If I perform a getent(1) on group Domain Users I get nothing, if I perform a getent(1) on group unixgroup I get the expected results. The other thing is
Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
On 14 May 2012 18:58, David Disseldorp dd...@suse.de wrote: Hi Javier, On Mon, 14 May 2012 17:48:09 +0200 Javier Conti javier.co...@gmail.com wrote: upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. I checked everything (I know) from the Samba point of view, and it almost seems ok, but wbinfo -i fails as follows: # wbinfo -i myuser failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user myuser Thanks for your report. As this version of Samba is vendor supported, I'd encourage you to raise this issue at bugzilla.novell.com. Do you also encounter this error with winbind use default domain = no configured, running wbinfo -i MYDOMAIN\\myuser? Hi David, as you suggested, I filed a bug there. I also tried configuring winbind use default domain = no but all the symptoms seems the same (I obviously restarted winbindd). Thanks, Javier Cheers, David -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
On 05/15/2012 1:12 AM, Javier Conti wrote: On 14 May 2012 18:58, David Disseldorpdd...@suse.de wrote: Hi Javier, On Mon, 14 May 2012 17:48:09 +0200 Javier Contijavier.co...@gmail.com wrote: upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. I checked everything (I know) from the Samba point of view, and it almost seems ok, but wbinfo -i fails as follows: # wbinfo -i myuser failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user myuser Thanks for your report. As this version of Samba is vendor supported, I'd encourage you to raise this issue at bugzilla.novell.com. Do you also encounter this error with winbind use default domain = no configured, running wbinfo -i MYDOMAIN\\myuser? Hi David, as you suggested, I filed a bug there. I also tried configuring winbind use default domain = no but all the symptoms seems the same (I obviously restarted winbindd). Thanks, Javier Cheers, David Javier, It is possible that you are seeing this: https://bugzilla.samba.org/show_bug.cgi?id=8676 I can confirm that it is still present in 3.6.5. Dale -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
Hi Javier, Javier Conti wrote: Dear list, upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. Although I tried many changes to the config, according to some hints found on the web, this is what I was using with Samba 3.4.3: [global] workgroup = MYDOMAIN realm = MYREALM security = ADS idmap backend = idmap_ad idmap uid = 64000 - 64999 idmap gid = 64000 - 64999 idmap config MYDOMAIN : default = yes idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema_mode = rfc2307 winbind use default domain = yes winbind nss info = rfc2307 winbind offline logon = yes winbind refresh tickets = yes [...] Any hints on what has changed with Samba 3.6.3 and/or what to change to adapt the configuration to 3.6.3 (if necessary)? Some comments: The above config makes no real sense for me, neither for 3.4 nor for 3.6: * The parameter idmap config DOMAIN : default = yes/no has been removed in samba 3.3. It only existed from 3.0.25 to 3.2. (http://www.samba.org/samba/history/samba-3.3.0.html) * You are using the backend ad (or idmap_ad which is a deprecated synonym) both in idmap config MYDOMAIN : backend and in idmap backend. Both with different ranges. This does not seem to make sense to me. It is necessary to specify a writable backend for the catch all default idmap configuration, e.g. tdb or ldap. In 3.6, the idmap backend has been replaced by idmap config * : backend, etc. A valid config for 3.4 would be: ~ [global] workgroup = MYDOMAIN idmap backend = tdb idmap uid = x-y idmap gid = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ The corresponding for 3.6: ~ [global] workgroup = MYDOMAIN idmap config * : backend = tdb idmap config * : range = x-y idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 1000-5 idmap config MYDOMAIN : schema mode = rfc2370 ~ I checked everything (I know) from the Samba point of view, and it almost seems ok, but wbinfo -i fails as follows: # wbinfo -i myuser failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user myuser Using the same user, for example, I can do: # wbinfo -n myuser S-1-5-21-828208052-1092558876-1846952604-22794 SID_USER (1) # wbinfo -n Domain Users S-1-5-21-828208052-1092558876-1846952604-513 SID_DOM_GROUP (2) # wbinfo -s S-1-5-21-828208052-1092558876-1846952604-22794 MYDOMAIN\myuser 1 # wbinfo -s S-1-5-21-828208052-1092558876-1846952604-513 MYDOMAIN\Domain Users # net -Uadminuser user info myuser |head Enter adminuser's password: domain users [...] # net -Uadminuser ads user |grep myuser Enter adminuser's password: myuser Obviously, id(1) and getent(1) fail. What I get is: [2012/05/14 16:50:47.958484, 6] winbindd/winbindd.c:792(new_connection) accepted socket 25 [2012/05/14 16:50:47.958604, 10] winbindd/winbindd.c:642(process_request) process_request: request fn INTERFACE_VERSION [2012/05/14 16:50:47.958644, 3] winbindd/winbindd_misc.c:384(winbindd_interface_version) [ 5756]: request interface version [2012/05/14 16:50:47.958705, 10] winbindd/winbindd.c:738(winbind_client_response_written) winbind_client_response_written[5756:INTERFACE_VERSION]: delivered response to client [2012/05/14 16:50:47.958771, 10] winbindd/winbindd.c:642(process_request) process_request: request fn WINBINDD_PRIV_PIPE_DIR [2012/05/14 16:50:47.958808, 3] winbindd/winbindd_misc.c:417(winbindd_priv_pipe_dir) [ 5756]: request location of privileged pipe [2012/05/14 16:50:47.958870, 10] winbindd/winbindd.c:738(winbind_client_response_written) winbind_client_response_written[5756:WINBINDD_PRIV_PIPE_DIR]: delivered response to client [2012/05/14 16:50:47.958939, 6] winbindd/winbindd.c:792(new_connection) accepted socket 26 [2012/05/14 16:50:47.958995, 6] winbindd/winbindd.c:840(winbind_client_request_read) closing socket 25, client exited [2012/05/14 16:50:47.959058, 10] winbindd/winbindd.c:615(process_request) process_request: Handling async request 5756:GETPWNAM [2012/05/14 16:50:47.959097, 3]
[Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
Dear list, upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. I checked everything (I know) from the Samba point of view, and it almost seems ok, but wbinfo -i fails as follows: # wbinfo -i myuser failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user myuser Using the same user, for example, I can do: # wbinfo -n myuser S-1-5-21-828208052-1092558876-1846952604-22794 SID_USER (1) # wbinfo -n Domain Users S-1-5-21-828208052-1092558876-1846952604-513 SID_DOM_GROUP (2) # wbinfo -s S-1-5-21-828208052-1092558876-1846952604-22794 MYDOMAIN\myuser 1 # wbinfo -s S-1-5-21-828208052-1092558876-1846952604-513 MYDOMAIN\Domain Users # net -Uadminuser user info myuser |head Enter adminuser's password: domain users [...] # net -Uadminuser ads user |grep myuser Enter adminuser's password: myuser Obviously, id(1) and getent(1) fail. What I get is: [2012/05/14 16:50:47.958484, 6] winbindd/winbindd.c:792(new_connection) accepted socket 25 [2012/05/14 16:50:47.958604, 10] winbindd/winbindd.c:642(process_request) process_request: request fn INTERFACE_VERSION [2012/05/14 16:50:47.958644, 3] winbindd/winbindd_misc.c:384(winbindd_interface_version) [ 5756]: request interface version [2012/05/14 16:50:47.958705, 10] winbindd/winbindd.c:738(winbind_client_response_written) winbind_client_response_written[5756:INTERFACE_VERSION]: delivered response to client [2012/05/14 16:50:47.958771, 10] winbindd/winbindd.c:642(process_request) process_request: request fn WINBINDD_PRIV_PIPE_DIR [2012/05/14 16:50:47.958808, 3] winbindd/winbindd_misc.c:417(winbindd_priv_pipe_dir) [ 5756]: request location of privileged pipe [2012/05/14 16:50:47.958870, 10] winbindd/winbindd.c:738(winbind_client_response_written) winbind_client_response_written[5756:WINBINDD_PRIV_PIPE_DIR]: delivered response to client [2012/05/14 16:50:47.958939, 6] winbindd/winbindd.c:792(new_connection) accepted socket 26 [2012/05/14 16:50:47.958995, 6] winbindd/winbindd.c:840(winbind_client_request_read) closing socket 25, client exited [2012/05/14 16:50:47.959058, 10] winbindd/winbindd.c:615(process_request) process_request: Handling async request 5756:GETPWNAM [2012/05/14 16:50:47.959097, 3] winbindd/winbindd_getpwnam.c:56(winbindd_getpwnam_send) getpwnam myuser [2012/05/14 16:50:47.959135, 1] ../librpc/ndr/ndr.c:284(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName in: struct wbint_LookupName domain : * domain : 'MYDOMAIN' name : * name : 'MYUSER' flags: 0x0008 (8) [2012/05/14 16:50:47.959276, 1] ../librpc/ndr/ndr.c:284(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName out: struct wbint_LookupName type : * type : SID_NAME_USER (1) sid : * sid : S-1-5-21-828208052-1092558876-1846952604-22794 result : NT_STATUS_OK [2012/05/14 16:50:47.959404, 1] ../librpc/ndr/ndr.c:284(ndr_print_function_debug) wbint_QueryUser: struct wbint_QueryUser in: struct wbint_QueryUser sid : * sid : S-1-5-21-828208052-1092558876-1846952604-22794 [2012/05/14 16:50:47.959499, 1] ../librpc/ndr/ndr.c:284(ndr_print_function_debug) wbint_QueryUser: struct wbint_QueryUser out: struct wbint_QueryUser info : * info: struct wbint_userinfo acct_name: * acct_name: 'myuser' full_name: * full_name: 'Lastname Firstname' homedir : * homedir : '/home/myuser' shell: * shell: '/bin/bash' primary_gid : 0x2710 (1) user_sid : S-1-5-21-828208052-1092558876-1846952604-22794 group_sid: S-1-5-21-828208052-1092558876-1846952604-513 result : NT_STATUS_OK [2012/05/14 16:50:47.959686, 10] winbindd/wb_sid2uid.c:56(wb_sid2uid_send) idmap_cache_find_sid2uid found 10106 [2012/05/14
Re: [Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3
Hi Javier, On Mon, 14 May 2012 17:48:09 +0200 Javier Conti javier.co...@gmail.com wrote: upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3 to 3.6.3. I was successfully using idmap_ad to authenticate users but after the upgrade it stopped working and users are not seen by the OS. Obviously the users I want to see on the Linux server have all RFC2307 attributes populated and are seen by all other SLES11 SP1 servers. I checked everything (I know) from the Samba point of view, and it almost seems ok, but wbinfo -i fails as follows: # wbinfo -i myuser failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user myuser Thanks for your report. As this version of Samba is vendor supported, I'd encourage you to raise this issue at bugzilla.novell.com. Do you also encounter this error with winbind use default domain = no configured, running wbinfo -i MYDOMAIN\\myuser? Cheers, David -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
