[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