I'm using Samba 3.5.6 on Fedora 14 together with 389-ds (1.2.7) as an LDAP server. So far this has been working ok, but since I upgraded to Fedora 14 it fails. I put back my backup for most of my LDAP and Samba files, but that didn't work. The problem I have is:
If I keep my smb.conf like it was before, the log.smbd will show:
Failed to issue the StartTLS instruction: Connect error
[2011/01/09 23:26:03.379381, 1] lib/smbldap.c:1330(another_ldap_try)
Connection to LDAP server failed for the 1 try!
This used to work fine before. ldapsearch -ZZ works fine and my certificated are valid till 2020, so the problem doesn't seem to be with my LDAP server. Note that 389-ds stores the certificates in the LDAP dir itself.
If I add the line: ldap ssl = off to my smb.conf, Samba starts fine but when I try to log into Windows 7 I get greeted with a message that the trust relationship between this workstation and the primary domain failed. log.smbd tells me:
[2011/01/10 10:30:29.618113, 0] rpc_server/srv_netlog_nt.c:714(_netr_ServerAuthenticate3)
_netr_ServerAuthenticate3: netlogon_creds_server_check failed. Rejecting auth request from client ATHENA machine account ATHENA$
I hope the latter starts working again if I get startTLS working again. I have a vague memory of the time when I set this up, that the two are related, but I might be completely wrong. Anyone any idea where to look on fixing this?
The relevant part of my smb.conf:
workgroup = OLYMPUS
server string = Olympus domain PDC
interfaces = lo, br0
passdb backend = ldapsam:ldap://zeus.olympus.lan/
passwd program = /usr/sbin/smbldap-passwd %u
username map = /etc/samba/smbusers
smb ports = 139
socket options = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
time server = Yes
unix password sync = Yes
load printers = yes
printing = cups
printcap name = cups
cups options = raw
add user script = /usr/sbin/smbldap-useradd -m '%u'
delete user script = /usr/sbin/smbldap-userdel %u
add group script = /usr/sbin/smbldap-groupadd -p '%g'
delete group script = /usr/sbin/smbldap-groupdel '%g'
add user to group script = /usr/sbin/smbldap-groupmod -m '%u' '%g'
delete user from group script = /usr/sbin/smbldap-groupmod -x '%u' '%g'
set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u'
# add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u" --gid "Domain_Computers" && /usr/sbin/smbldap-useradd -i -w -n '%u'
add machine script = /usr/sbin/smbldap-useradd -w -i -n '%u'
logon script = %U.bat
logon path = \\%L\profiles\%U
logon drive = U:
logon home = \\%L\%U
domain logons = Yes
os level = 65
preferred master = Yes
domain master = Yes
wins support = Yes
guest ok = Yes
ldap admin dn = cn=Directory Manager
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Computers
ldap passwd sync = yes
ldap suffix = dc=olympus,dc=lan
ldap user suffix = ou=People
ldap ssl = off
idmap uid = 15000-20000
idmap gid = 15000-20000
winbind offline logon = Yes
The last lines of my ldap.conf (If I'm not mistaken, they're relevant for where samba finds the info for startTLS):
I found some info which suggest that it might be relevant that my backup wasn't that recent. Apparently domain member servers and workstations periodically change the Machine Trust Account password, so that might explain part of my problem. However, that still doesn't explain the startTLS problem. I'll try to take my win 7 client out of the domain and put it back in (with ssl off).
As I couldn't seem to enter the right password I tried to change that, which led to this message:
ldapsam_modify_entry: LDAP Password could not be changed for user root: Confidentiality required
Operation requires a secure connection.
This confirms for me that getting ssl working again is key to fixing my problem.