Our Samba installation is working perfectly, thanks to John Terpstra's
generous assistance. I'm
pretty sure that I would have been at it for a couple of weeks and
still not gotten all of the way
there. I'll try to summarize what was done, since it never hurts to
mention a few things too
many times.
While I have read John's book online, and tried to follow it, there
were times when I would try
something I read about on the web. I think it is fair to say that
this was my biggest problem,
since it introduced a number of issues. My lack of experience with
LDAP didn't help, although
there is a big difference between reading about LDAP and working with it.
First off, the sample smb.conf which is shipped with Fedora is at best
a good starting point. This
is probably the case with other distributions as well. The file
contains many settings which
Samba defaults to, and the result is clutter and a possible source of
confusion. Enter "testparm"
to clear things up. I have used testparm to check my smb.conf (and
indeed this is how the
man page describes this tool). Using "testparm -s smb.conf.old >
smb.conf.new" we get a trimmed
down version of the file. John described this as Samba's view of the
file, which may be different
from the person editing it.
Looking at the changes testparm made:
* converted the domain name to upper case
* removed "security = user"
* removed the comments
* removed "obey pam restrictions = no"
* removed "username map = /etc/samba/smbusers"
* removed some windbind directives
* removed "client use spnego = true"
* removed "local master = yes" (since server is configured as a PDC,
this is redundant)
* removed "dns proxy = yes"
* removed "writable = yes" from some shares
* removed "guest ok = yes" from some shares, although left it in
[netlogon]
* removed "read only = yes" and "writable = no" from
[netlogon]
* removed "public = yes" from some shares
* removed "browsable = yes" from some shares
Stating some of the default explicitly might be a form of
documentation, but a comment
accomplishes the same thing.
After that, we come to outright misconfigurations in smb.conf:
* not quoting variables like "%u" on command lines (which introduces a
security hole)
* the socket options were removed, as it was hurting performance on
the new versions of Samba
* a machine password timeout was removed
* I had home directories specified as "\\server\home\%U" instead of
"\\server\%U"
* I was inadvertantly sharing the entire set of home directories
rather than letting Samba do its thing
* I was specifying a create and directory mask on the [profiles]
share, and it was wrong
* I was missing "profile acls = Yes" on [profiles]
* I had the profiles share browsable
On the LDAP side, the default sambaNextRid for the domain was too low.
Some accounts were recreated so
that they had a reasonable SID.
The profile directories had group ownership set to some local groups,
rather than the well-known "Domain Users".
I opted to remove all of the existing profiles and start fresh, since
this is not yet a production machine.
The PDC had not been joined to the domain. I was somehow under the
impression that the PDC was automatically in
the domain, but that "net rpc join" needed to be done.
I think this is the full list, and as you can see there was a lot
which needed to be done. Which just goes to
show that no matter how well you think you may have read the book,
even reasonably careful people can skip
important things. (Although John may disagree with my use of
"reasonably careful" when describing myself).
John also pointed me to LdapAdmin. I was looking for something like
this, and was under the impression that this
was commercial. I was confusing the open-source product with
Softerra's commercial "LDAP Administrator". Hopefully
others don't make this mistake, since this tool drastically reduces
the amount of work needed to maintain an LDAP database.
Again, my thanks to John for helping us out.
Jon Doran
at the LARC lab at the University of North Texas
