[Samba] Group and Client Access Problems w/Samba 3

Wil Cooley wcooley at nakedape.cc
Tue Jan 20 23:55:19 GMT 2004


[Sorry this is so long; I've tried to be thorough.  Please CC: any
responses to me, because I haven't gotten any messages from the Samba
list in over 15 hours and am concerned something is awry with my
subscription.]

I have recently set up a Samba 3.0.1 PDC/BDC installation with LDAP
master/slave.  It has been mostly successful, however, there are a few
niggling issues that remain.  First, a bit about our setup:  There are
two sites connected via VPN, the headquaters in Alaska are the PDC and
LDAP master, and the remote site in Oregon the BDC and LDAP slave.  For
simplicity, I will refer to them as the AK and OR sites.  The AK site
has the sever at 192.168.0.10 and the OR site at 192.168.2.10.

Software version is Samba 3.0.1, built from a self-rolled RPM by
modifying the Red Hat Enterprise 3 SRPM, and removed all patches
(because the didn't apply cleanly).  The server on the AK site is Red
Hat Linux 9 and the OR site is Red Hat Enterprise Linux 3.  Both are
running the same binary of Samba.

Aside from the errors below, which themselves may be cosmetic or may be
symptomatic of other problems, there is one problem for which I cannot
precisely find a corresponding problem in the logs.  Previously, the
sites were configured with one 2.2.8 PDC on the AK site and the OR
router gave the WINS server via DHCP.  The OR users were almost entirely
peer-to-peer, since there wasn't a local server and the remote server
was far too slow over the VPN.  Now, there are intermittent problems
with p2p access.  The workstations appear on the browse lists, however,
attempting to list shares results in odd errors on the workstations,
like "internal Windows 2000 errors" and some strange things that look
like format-strings not being interpolated, like "0x%1 %2".

I have noticed schannel errors in the logs, like this:

[2004/01/20 09:59:06, 0] rpc_server/srv_pipe.c:api_pipe_netsec_process(1371)
  failed to decode PDU
[2004/01/20 09:59:06, 0] rpc_server/srv_pipe_hnd.c:process_request_pdu(605) process_request_pdu: failed to do schannel processing.

---
Here is how 'configure' was run (RPM macro):

%configure \
        --with-acl-support \
        --with-automount \
        --with-codepagedir=%{_datadir}/samba/codepages \
        --with-fhs \
        --with-libsmbclient \
        --with-lockdir=/var/cache/samba \
        --with-mmap \
        --with-pam \
        --with-pam_smbpass \
        --with-piddir=/var/run \
        --with-privatedir=%{_sysconfdir}/samba \
        --with-quotas \
        --with-smbmount \
        --with-swatdir=%{_datadir}/swat \
        --with-syslog \
        --with-utmp \
        --with-vfs \
        --without-smbwrapper

OpenLDAP is 2.0.27-11 on the OK site and 2.0.27-8 on the AK site.

The global section of smb.conf from AK site (PDC):
[global]
        workgroup = DOMAIN
        server string =
        passdb backend = ldapsam:ldap://localhost
        passwd program = /usr/local/sbin/smbldap-passwd %u
        passwd chat = *New*password* %n\n *Retype*new*password* %n\n *all*authentication*tokens*updated*
        max log size = 50000
        time server = Yes
        add user script = /usr/local/sbin/smbldap-useradd -m "%u"
        delete user script = /usr/local/sbin/smbldap-userdel "%u"
        add group script = /usr/local/sbin/smbldap-groupadd -p "%g"
        delete group script = /usr/local/sbin/smbldap-groupdel "%g"
        add user to group script = /usr/local/sbin/smbldap-groupmod -m "%u" "%g"        
        delete user from group script = /usr/local/sbin/smbldap-groupmod -x "%u" "%g"
        set primary group script = /usr/local/sbin/smbldap-usermod -g "%g" "%u"
        add machine script = /usr/local/sbin/smbldap-useradd -w "%u"
        logon script = %m.bat
        logon path =
        logon drive = c:
        logon home = \\pdc\%U
        domain logons = Yes
        os level = 60
        preferred master = Yes
        domain master = Yes
        wins support = Yes
        ldap suffix = dc=example,dc=com
        ldap machine suffix = ou=Computers
        ldap user suffix = ou=People
        ldap group suffix = ou=Group
        ldap admin dn = cn=SambaAdministrator,dc=example,dc=com
        ldap passwd sync = Yes
        ldap delete dn = Yes

and the OR side (BDC):

[global]
        workgroup = DOMAIN
        server string =
        passdb backend = ldapsam:ldap://localhost
        time server = Yes
        logon script = %m.bat
        logon path =
        logon drive = H:
        logon home = \\bdc\%U
        domain logons = Yes
        preferred master = Yes
        domain master = No
        wins server = 192.168.0.200
        ldap suffix = dc=example,dc=com
        ldap machine suffix = ou=Computers
        ldap user suffix = ou=People
        ldap group suffix = ou=Group
        ldap admin dn = cn=SambaAdministrator,dc=example,dc=com
        ldap passwd sync = Yes


DHCP is configured on each end to provide the local server's IP address
for WINS to workstations.

The basic group mappings are set up: 512/Admins, 513/Users, 514/Guests,
created using the 'net groupmap add' command.  They are group type 2,
which from what I can tell means they're domain groups.

The users were also migrated from a Red Hat Linux installation, and all
users also have user-private groups.  I created domain maps for all of
these.  I noticed looking at the OpenLDAP logs that not only did Samba
look up the gidNumber from the user, it also searched for something like
'(&(gidNumber=XX)(memberUid=user))', which meant that each user had to
be added to his own primary group, which was unusual--you generally
don't need to list a user in /etc/groups for his primary group and the
PADL migration scripts make no such assumption (I'm not sure what RFC
2307 says, although I suspect it agrees with my presumption).  I would
consider this a minor bug and will file it officially if someone
responds affirmatively.

I'm getting this in the logs and it causes me some concern:

[2004/01/19 19:39:14, 10] passdb/pdb_get_set.c:pdb_set_init_flags(493)
  element 22 -> now SET
[2004/01/19 19:39:14, 10] passdb/pdb_get_set.c:pdb_set_init_flags(493)
  element 31 -> now SET
[2004/01/19 19:39:14, 10] passdb/pdb_get_set.c:pdb_set_init_flags(493)
  element 32 -> now SET
[2004/01/19 19:39:14, 10] passdb/pdb_get_set.c:pdb_set_init_flags(493)
  element 19 -> now SET
[2004/01/19 19:39:14, 10] passdb/pdb_get_set.c:pdb_set_init_flags(493)
  element 15 -> now SET
[2004/01/19 19:39:14, 10] passdb/pdb_get_set.c:pdb_set_init_flags(493)
  element 16 -> now SET
[2004/01/19 19:39:14, 10] passdb/pdb_get_set.c:pdb_set_init_flags(493)
  element 26 -> now SET
[2004/01/19 19:39:14, 0] groupdb/mapping.c:init_group_mapping(139)
  Failed to open group mapping database
[2004/01/19 19:39:14, 0] groupdb/mapping.c:get_group_from_gid(655)
  failed to initialize group mappingFailed to open group mapping database
[2004/01/19 19:39:14, 0] groupdb/mapping.c:get_group_from_gid(655)
  failed to initialize group mappingget_alias_user_groups: gid of user tmax3 doesn't exist. Check your /etc/passwd and /etc/group files

The GID of user 'tmax3' (a test account) does in fact exist, as a
posixAccount and sambaGroupMapping entry with the appropriate gidNumber
and sambaSID.  I notice that at about the same time there is a query for
'(objectClass=sambaGroupMapping)', and then a series of queries for
'(&(objectClass=posixGroup)(gidNumber=XX))', going through every group
that exists.  If find this behaviour curious and non-optimal.

Also, the SHT and other docs mention the idmap stuff, but only in
relation to winbind, which is not being used and is not necessary,
AFAICT.  Am I mistaken?  Do I need idmap/winbind with PDC/BDC+LDAP?

Wil
-- 
Wil Cooley                                 wcooley at nakedape.cc
Naked Ape Consulting                        http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Naked Ape Consulting                   http://nakedape.cc  *
* Cisco Support & Sales          http://nakedape.cc/r/cisco  *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba/attachments/20040120/bdf60000/attachment.bin


More information about the samba mailing list