I am wondering whether anyone might also be seeing the problems I am
currently encountering -- and maybe even someone knows of a solution
that I cannot seem to find.
First, to whet your appetite, the problem:
I have an otherwise functional samba+winbind system, that I am
primarily using winbind to instantiate users & groups from a
Win2K3-based ADS, to allow clients ssh/scp/sftp access to website
file storage.
Winbind appears to be working reasonably correctly - I have 3.0.24
installed on this RHEL4 system. I have successfully tweaked the
pam.d/sshd config to restrict ssh login access to members of a
particular group. Once on the system, home directories are properly
created if necessary, and they can successfully modify/add files in
their home directory, in /tmp/, as necessary. As long as it is on
local file storage...
This system NFS mounts the remote file storage resource on a backend
RHEL4 server. The public facing web frontends also mount these same
resources. Here is where things get hinky -- some users can write
to the directories on the NFS mount, and some cannot. If the
directory in question is owned by the user, then no problems
writing. If not, but the directory's owning group contains the user
as a member, then only sometimes can the user add/change/remove files
in the directory.
The first thing I would think to check here are the permissions --
directory permissions in my testcase are 2775, file perms are 0664 --
shouldn't be any problems there, right?
The most interesting behavior is that some groups work and some do
not. If I set the group for a directory to "Domain Users", then all
can successfully write to it. I can use "Domain Admins" also, and
the domain admin users can write to it. Set it to another group that
we created mid-year last year, and also those users have no
problems. However, set the test directory to a group that was
created last week, and permission is denied. The same denial if I
use a group that was created over a month ago.
Now, I have created directories on the local filesystem, set them to
each of these groups and successfully written to them while su'd to
the same user account that cannot write under some of the groups on
the NFS mounted filesystem.
At first I thought it was groups with underscores in the group name -
a recently adopted convention on our AD, but a recently created test
group using hyphens instead of underscores exhibits the same failure
state. I have eliminated ACLs & xattrs from the equation, as the
same behavior exists on mounts that are not mounted with those
options and whose underlying filesystems don't have the options either.
I also thought it might have something to do with nested groups, but
even simple groups with only users as members exhibit the failure
over NFS. I have had the thought that it could be the length of
some of the groupnames, as some of them are pretty long: the longest
is 64 bytes. The one I did most testing with is only 10 bytes long, however.
I have even tried groups created in the domain root versus groups
created under various OUs -- all recent groups exhibit the same
failure state. The problem appears to apply to groups created after
a certain point, but that point is still to be narrowed down. (I'm
currently running with 737 groups and 3797 users, according to wbinfo -g &
-u.)
Details & configs:
We have a somewhat unusual domain structure:
1) an empty root domain, with our main domain in the same forest
2) a related single domain/forest with a two-way forest-level trust
3) an old NT4 domain with two-way trust (unsure of forest-level or
domain-level)
(I limited my testing to users and groups from the main domain, to
try to reduce externalities.)
smb.conf: (output from testparm)
-----------------------------
[global]
workgroup = ACES
realm = COLLEGE.ACESNET.UIUC.EDU
netbios name = ACES-SITE-MAINT
server string = %L (Samba v%v)
security = ADS
obey pam restrictions = Yes
password server = college.acesnet.uiuc.edu
username map = /etc/samba/smbusers
client NTLMv2 auth = Yes
client lanman auth = No
client plaintext auth = No
log file = /var/log/samba/%m.log
max log size = 0
name resolve order = host lmhosts wins bcast
deadtime = 15
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
local master = No
dns proxy = No
wins server = 128.174.x.x, 128.174.x.x
idmap uid = 10000-100000000
idmap gid = 10000-100000000
template shell = /bin/bash
winbind cache time = 10
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
create mask = 0664
directory mask = 02775
inherit permissions = Yes
inherit acls = Yes
case sensitive = No
-----------------------------
krb5.conf:
-----------------------------
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
ticket_lifetime = 24000
default_realm = COLLEGE.ACESNET.UIUC.EDU
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
COLLEGE.ACESNET.UIUC.EDU = {
kdc = college.acesnet.uiuc.edu:88
admin_server = college.acesnet.uiuc.edu:749
default_domain = college.acesnet.uiuc.edu
}
ACESNET.UIUC.EDU = {
kdc = acesnet.uiuc.edu:88
admin_server = acesnet.uiuc.edu:749
default_domain = acesnet.uiuc.edu
}
AD.UIUC.EDU = {
kdc = ad.uiuc.edu
admin_server = ad.uiuc.edu
default_domain = ad.uiuc.edu
}
EXTENSION.UIUC.EDU = {
kdc = extension.uiuc.edu
admin_server = extension.uiuc.edu
default_domain = extension.uiuc.edu
}
[domain_realm]
.college.acesnet.uiuc.edu = COLLEGE.ACESNET.UIUC.EDU
college.acesnet.uiuc.edu = COLLEGE.ACESNET.UIUC.EDU
.acesnet.uiuc.edu = ACESNET.UIUC.EDU
acesnet.uiuc.edu = ACESNET.UIUC.EDU
.ad.uiuc.edu=AD.UIUC.EDU
ad.uiuc.edu=AD.UIUC.EDU
.extension.uiuc.edu = EXTENSION.UIUC.EDU
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
-----------------------------
nssswitch.conf:
-----------------------------
...
passwd: files winbind
shadow: files winbind
group: files winbind
...
-----------------------------
Any insights that anyone can offer will be extremely welcome.
(Frankly, even just hearing that someone else is seeing a similar
problem would be welcome at this point... ;-)
Thanks,
-D
Don Meyer <dlmeyer@uiuc.edu>
Network Manager, ACES Academic Computing Facility
Technical System Manager, ACES TeleNet System
UIUC College of ACES, Information Technology and Communication Services
"They that can give up essential liberty to obtain a little
temporary safety,
deserve neither liberty or safety." -- Benjamin Franklin, 1759