samba - May 2011 - Error in Configuring CTDB, Winbind and AD

Hello Samba Users,

After going through a lot of hassles, i have ended up coming mentioned below
samba configuration.  But it is still far from a working stage.

wbinfo -t, -u and -g works. But wbinfo -i works on few nodes but doesn't
work on few resulting in error "Could not get info for user
<username>"

Strange part is that i could see these messages
"/var/log/samba/log.winbindd-idmap"

[2011/05/10 15:40:54.147924,  1]
winbindd/idmap_ad.c:651(idmap_ad_sids_to_unixids)
  Could not get unix ID
[2011/05/10 15:54:41.509152,  1]
winbindd/idmap_ad.c:651(idmap_ad_sids_to_unixids)
  Could not get unix ID

is it due to some lower limit in my idmap ? is it something else?

Samba version 3.5.8 , ctdb 1.0-112  CentOS 5.6

Current Global Section
[global]
   strict locking = no
   socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=131072
SO_RCVBUF=131072
   read raw = yes
   server string = %h
   write raw = yes
   oplocks = yes
   max xmit = 131072
   dead time = 15
   getwd cache = yes
   use sendfile=yes
   block size = 131072
   load printers = no
   clustering = yes

   workgroup = WINHPC
   netbios name = WINHPC-NAS
   server string = WINHPC CIFS
   password server = hpchead.winhpc.local
   realm = WINHPC.LOCAL
   security = ADS
   kerberos method = system keytab
   idmap config WINHPC : backend = ad
   idmap config WINHPC : readonly = yes
   idmap config WINHPC : schema_mode = rfc2307
   idmap config WINHPC : range = 1000-4000000000
   idmap uid = 1000-4000000000
   idmap gid = 1000-4000000000
   winbind nss info = rfc2307
   winbind use default domain = yes
   winbind enum users = yes
   winbind enum groups = yes
   winbind offline logon = true
   winbind cache time = 5
   winbind refresh tickets = true
   winbind nested groups = yes
   winbind separator = +

   template shell = /sbin/nologin
   machine password timeout = 999999999

   log file = /var/log/samba/log.%m
   max log size = 100
   log level = 3

   passdb backend = tdbsam


[hpc]
        case sensitive = no
        comment = share for HPC
        path = /mnt/glustervol01
        public = no
        writable = yes
        printable = no
        admin users = @"WINHPC\Domain Admins"
        valid users = @"WINHPC\Domain Users",MDC
        write list = @"WINHPC\Domain Users",MDC


I would be thankful for any inputs you all have.

Regards
--
Harshavardhana

Adding to that access to the shares fail, this config works like charm
without ctdb. But i am not entirely sure how its related to CTDB
configuration.

Seems like the credentials are not synced across properly by ctdb.

On Tue, May 10, 2011 at 12:57 PM, Harshavardhana
<harsha at harshavardhana.net>wrote:
> Hello Samba Users,
>
> After going through a lot of hassles, i have ended up coming mentioned
> below samba configuration.  But it is still far from a working stage.
>
Regards
--
Harshavardhana

Harshavardhana  wrote on 05/10/2011 09:57:06 PM:

> [2011/05/10 15:40:54.147924,  1]
> winbindd/idmap_ad.c:651(idmap_ad_sids_to_unixids)
>   Could not get unix ID
> [2011/05/10 15:54:41.509152,  1]
> winbindd/idmap_ad.c:651(idmap_ad_sids_to_unixids)
>   Could not get unix ID
>    idmap config WINHPC : backend = ad
>    idmap config WINHPC : readonly = yes
>    idmap config WINHPC : schema_mode = rfc2307
>    idmap config WINHPC : range = 1000-4000000000
>    idmap uid = 1000-4000000000
>    idmap gid = 1000-4000000000

This indicates that you have invalid values in your SFU
attributes in AD.
If a user wants to connect with the ad backend in place, the user
must have a uid and the Windows primary group also needs to have a gid
defined in the UNIX Attributes tab.
Besides that, you should not use overlapping ranges for idmap uid and the
domain specific range.

For WINHPC, you should limit the range to the numbers that you are planning
to use in AD and then use another disjunct range for idmap uid.

e.g.
idmap config WINHPC : range = 1000-40000
idmap uid = 50000-4000000000
idmap gid = 50000-4000000000


Regards,
Christian

Thanks solved it by using idmap rid backend.