I'm using an ldap-backed TNG PDC for domain logins with no problem.
I've got a samba 2.2.8a fileserver that doesn't seem to correctly map
usernames to domain SIDS. It is passing authentication requests to the
PDC correctly, and allows users to map non-public shares, write to their
home directories, etc. When a file's "security' attributes are
viewed in
windows explorer, the owner is \\fileserver\username, not
\\domain\username.
Accounts for the fileserver exist for both unix and smb in the ldap
directory, with the acctFlags in the smb tree set to W (I've tried with
the fags set to S as well with no change in behavior). I've joined the
domain from the fileserver with smbpasswd -j, and doing so changes the
lmPassword and ntPassword fields in ldap.
On the fileserver, the basic auth. configuration is:
security = domain
password server = fqdn.of.password.server
encrypt passwords = yes
What am I doing wrong here? Why isn't the samba 2.2.8a fileserver
seeing that username1 is DOMAIN\username1, not FILESERVER\username1?
One additional thing is that when using rpcclient on the fileserver and
running the querydominfo command I get:
rpcclient $> querydominfo
result was NT_STATUS_ACCESS_DENIED
rpcclient $>
enumalsgroups, though, shows groups that are in ldap, but I can't tell if
it's seeing them via the domain controller or via the unix pam facility:
rpcclient $> enumalsgroups domain
group:[sys] rid:[0x...]
group:[tty] rid:[0x...]
group:[disk] rid:[0x...]
group:[mem] rid:[0x...]
group:[kmem] rid:[0x...]
group:[wheel] rid:[0x...]
group:[man] rid:[0x...]
group:[dip] rid:[0x...]
group:[lock] rid:[0x...]
group:[users] rid:[0x...]
group:[slocate] rid:[0x...]
group:[floppy] rid:[0x...]
group:[utmp] rid:[0x...]
group:[dasadm1] rid:[0x....]
group:[db2grp1] rid:[0x....]
group:[db2fgrp1] rid:[0x....]
group:[marketing] rid:[0....]
group:[sales] rid:[0x....]
group:[integrators] rid:[0x....]
rpcclient $>
Through db2fgrp1 the domains are posix-only, after that the groups are
both posix and smb.
Thanks in advance for any help you can give me here.
--
Michael D. Jurney
mike@jurney.org
