[Samba] Error: _netr_ServerAuthenticate2: netlogon_creds_server_check failed.

Christopher Springer cspringer at brcrp.com
Wed Jan 12 14:32:48 MST 2011


OS Fedora 13

rpm -qa | grep openldap

openldap-clients-2.4.21-4.fc13.i686
openldap-2.4.21-4.fc13.i686
openldap-servers-2.4.21-4.fc13.i686
openldap-devel-2.4.21-4.fc13.i686

rpm -qa | grep samba

samba-common-3.5.4-62.fc13.i686
samba-3.5.4-62.fc13.i686
samba-winbind-clients-3.5.2-60.fc13.i686
samba-doc-3.5.4-62.fc13.i686
samba-client-3.5.4-62.fc13.i686

(Note:  for our config...winbind is unneeded

slapd.conf - Master Server
---------------------------------

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#

include		/etc/openldap/schema/corba.schema
include		/etc/openldap/schema/core.schema
include		/etc/openldap/schema/cosine.schema
include		/etc/openldap/schema/duaconf.schema
include		/etc/openldap/schema/dyngroup.schema
include		/etc/openldap/schema/inetorgperson.schema
include		/etc/openldap/schema/java.schema
include		/etc/openldap/schema/misc.schema
include		/etc/openldap/schema/nis.schema
include		/etc/openldap/schema/openldap.schema
include		/etc/openldap/schema/ppolicy.schema
include		/etc/openldap/schema/collective.schema
include		/etc/openldap/schema/samba.schema

# Allow LDAPv2 client connections.  This is NOT the default.
allow bind_v2

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral	ldap://root.openldap.org

pidfile		/var/run/openldap/slapd.pid
argsfile	/var/run/openldap/slapd.args

# Load dynamic backend modules:
# modulepath	/usr/lib/openldap # or /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la

# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it.  Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem

# Sample security restrictions
#	Require integrity protection (prevent hijacking)
#	Require 112-bit (3DES or better) encryption for updates
#	Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#	Root DSE: allow anyone to read it
#	Subschema (sub)entry DSE: allow anyone to read it
#	Other DSEs:
#		Allow self write access
#		Allow authenticated users read access
#		Allow anonymous users to authenticate
#	Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################

database	bdb
suffix		"dc=example,dc=com"
checkpoint	1024 15
rootdn		"cn=Manager,dc=example,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw		rootpass


# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory	/var/lib/ldap

# Indices to maintain for this database
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
#     bindmethod=sasl saslmech=GSSAPI
#authcId=host/ldap-master.example.com at EXAMPLE.COM
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

# enable monitoring
# database monitor

# allow onlu rootdn to read the monitor
#access to *
#        by dn.exact="cn=Manager,dc=example,dc=com" write
#        by * none
access to attrs=userPassword,shadowLastChange,shadowMax,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange,sambaAcctFlags
	by dn="cn=Manager,dc=example,dc=com" write
	by self write
	by anonymous auth
	by * none
access to *
	by * read
#access to *
#	by * write



smb.conf - Master Server
---------------------------------

[global]
log level = 1
workgroup = DOMAIN
netbios name = SYSNAME
passdb backend = ldapsam:ldap://127.0.0.1
username map = /etc/samba/smbusers
printcap name = cups
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/smbldap-useradd -w '%u'
logon script = scripts/%U.bat
logon path =
logon drive =
security = user
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
wins support = Yes
smb ports = 139
lanman auth = yes
ldap suffix = dc=example,dc=com
ldap machine suffix = ou=Computers
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=Manager,dc=example,dc=com
ldap ssl = no
ldap passwd sync = yes
printing = cups

[netlogon]
comment = Network Logon Service
path = /pub
guest ok = Yes
browseable = No


My question to you is...why doesn't your PDC access your LDAP server?  
My configuration is a Samba domain with LDAP backend database...just FYI.

Chris


On 01/12/2011 01:49 PM, Martin Hochreiter wrote:
> Hi Christopher!
>
> Thank you for that information, I am very much appreciate any deeper 
> information on that issue.
> Is there a chance that you give me the config of your central (major) 
> ldap server and your smb.conf so we have the
> chance to compare it with our system, please?
>
> We see the same error but our PDC does directly access the main ldap 
> server so it should not be a
> problem of an update - reference ...
>
> It would be nice to know the versions of your system too (we use 
> ubuntu 8.04 and Centos 5.5 with ldap 2.4.XX and Samba 3.5.6)
>
> Thank you very much!
>
> regards
> Martin
>
>
> Am 12.01.2011 17:37 schrieb Christopher Springer:
>> I've finally found the solution (or at least in my case) to this 
>> problem.
>>
>> After looking at the logs for LDAP (slapd) I found that every time a
>> system on the domain tried to update it's associated account
>> information in the database I would receive the following error:
>>
>> RESULT tag=103 err=53 text=shadow context; no update referral
>>
>> This lead me to find that the account information in LDAP was not
>> being updated...however the machine's domain user accounts would still
>> be able to login so it wasn't a major issue...just EXTREMELY
>> annoying.  I added the following line in my slapd.conf file to tell
>> the slapd daemon where to send its updates since it's a read-only
>> local authentication server at the remote plants:
>>
>> updateref ldap://xxx.xxx.xxx.xxx
>>
>> The remote server now sends the account database updates to the
>> central master server and eventually replicates those changes back
>> down to the remote sites...and, thus, eliminating the annoying error
>> message that I was receiving in my samba and system logs.  Just for
>> reference, the original error was something similar to the following...
>>
>> _netr_ServerAuthenticate2: netlogon_creds_server_check failed.
>> Rejecting auth request from client XXXXXXXX machine account
>> XXXXXXXX$   or
>> _netr_ServerAuthenticate3: netlogon_creds_server_check failed.
>> Rejecting auth request from client XXXXXXXX machine account XXXXXXXX$
>>
>> Thanks all!  I hope this helps someone else.
>>
>> Chris
>>
>> On 08/19/2010 03:29 PM, Christopher Springer wrote:
>>>  My configuration is a multi-subnet, multi-subnet Samba/OpenLDAP
>>> configuration.  Everything works fine on both subnets but I'm getting
>>> the following error in /var/log/messages and in
>>> /var/log/samba/log.smbd...
>>>
>>> _netr_ServerAuthenticate2: netlogon_creds_server_check failed.
>>> Rejecting auth request from client XXX30874 machine account XXX30874$
>>>
>>> This messages seems to be repeated every time someone logs into their
>>> machine or when the machine has to contact the server for
>>> authentication purposes.  I have not had a chance to go through all
>>> of the logs and verify what OS's are the offenders but it appears
>>> that a lot of them are old WindowsNT4 machines.
>>>
>>> Please note that the only server on the subnet in question is the
>>> BDC.  It has a local, replicated LDAP directory against which logins
>>> are authenticated.  nmbd/wins is used for host name/netbios visibility.
>>>
>>> Any ideas to getting rid of this error in the log file?  Again, it
>>> appears that access to files is working fine...it's just an annoyance
>>> because I don't understand why it's happening.
>>>
>>> Thanks.
>>>
>>> Chris


More information about the samba mailing list