similar to: AD DC Replication failure

It did happen again and this time I was a little less panicked and took some time to figure out what happened. On my primary DC (SAMBA) I did not notice anything extraordinary. However, my secondary (VERDANDI) reported issues: root at verdandi:~# samba-tool drs showrepl Default-First-Site-Name\VERDANDI DSA Options: 0x00000001 DSA object GUID: a03bbb51-1dca-44ae-a4d9-7aa8cb4a1ace DSA

Today I had another automatic restart of my secondary DC because samba-tool drs showrepl showed errors. The restart was completed at 12:35. This is what I found in log.samba at log level 3: [2016/01/04 12:33:47.201892, 3] ../source4/rpc_server/drsuapi/getncchanges.c:2007(dcesrv_drsuapi_DsGetNCChanges) UpdateRefs on getncchanges for b19509be-c3ee-4a58-9fc9-afd61759a23f [2016/01/04

Hi Marc, >> The cause is that the password change didn' reach both AD DCs, but only >> one. The other one still had the old value as could be seen by >> samba-tool ldapcmp. Restarting the DCs and waiting for a couple of >> seconds brings them back to sync and Windows logons work as they used to. >> Any idea, what I should do next time to obtain valuable output

After deletion and recreation of the reverse zone Bind9 started again. Thanks to Rowland for the hint. However, bind complains that virtually all zones are duplicate and thus at least one issue is ignored. Since it's samba_dlz complaining there's either something wrong in the AD or in the DLZ module. The Bind does not have any other zones than the DLZ. I have trouble connecting

On 29/12/14 09:40, Lars Hanke wrote: > And some more information about this strange effect apparently no-one > has seen before. > > I now added the missing zone: > > samba-tool dns zonecreate verdandi 10.16.172.in-addr.arpa -U > Administrator > > and it claims that the zone is okay, but the next one is missing: > > Dec 29 10:31:12 verdandi named[2601]: Loading

And some more information about this strange effect apparently no-one has seen before. I now added the missing zone: samba-tool dns zonecreate verdandi 10.16.172.in-addr.arpa -U Administrator and it claims that the zone is okay, but the next one is missing: Dec 29 10:31:12 verdandi named[2601]: Loading 'ad.microsult.de' using driver dlopen Dec 29 10:31:12 verdandi named[2601]:

Just to clarify some things ... the Bind9 and Samba4 are both current Debian Jessie on amd64. So the applicable changelog would be http://metadata.ftp-master.debian.org/changelogs//main/b/bind9/testing_changelog Using 1:9.9.5.dfsg-6 the system worked nicely. Fixing a CVE pertaining to recursion does not easily link to DLZ issues. The system definitely has DLZ included. Otherwise it could not

I dug somewhat deeper into what is going on below and it seems even stranger. The reverse zone without SOA or NS does not even exist: root at verdandi:~# samba-tool dns query localhost 10.16.172.in-addr.arpa @ ALL -U Administrator Password for [AD\Administrator]: ERROR(runtime): uncaught exception - (9714, 'WERR_DNS_ERROR_NAME_DOES_NOT_EXIST') File

I just upgraded bind9 on my backup DC to 9.9.5-7-Debian and restarting the service failed: Dec 22 12:25:55 verdandi named[18534]: starting BIND 9.9.5-7-Debian -u bind -4 Dec 22 12:25:55 verdandi named[18534]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var'

Last month I struggled with a severe DLZ issue and today I could solve it. Credits for the important idea go to Peter Serbe, thanks! I checked the DNS contents using RSAT. There was nothing wrong with SOA nor NS entries, but the reverse zones were actually forward zones with proper names in the in-addr.arpa. domain. I built proper reverse zones and deleted the forward-reverse zones and Bind

Dear Roland, and here we have one reasons / prove regarding Debian and current Samba BIND DLZ issues : http://metadata.ftp-master.debian.org/changelogs//main/b/bind9/bind9_9.8.4.dfsg.P1-6+nmu2+deb7u3_changelog MSG >> " * disable dlz until we get a patch to make it build again" Well Debian Maintainers seems seeking missing the dlz patches that RHEL & SLES maintainers created

It's probably difting slightly off the topic, but I know that there are some people listening here, who have a decent expertise. I'm trying to setup a file server (nfs4 at ad.domain) and mount from a client (hunin at ad.domain) using the user database and especially Kerberos provided by my AD (samba at ad.domain). It already works nicely, if I forget about krb5, i.e. idmapd is

Recently I suddenly lose all permissions both for SMB and NFS4 on my Synology NAS.And similarly after poking some time in muddy waters, it suddenly works again. The NAS runs Samba 3.6.9. What I found, when the permissions were gone: 1. id user still working, didn't work last time so I assume a caching issue here 2. wbinfo -u same as above. This time still worked, last time only reported

This topic has been on the list two years ago, already, but apparently to no conclusion. I'm trying to join a Debian Wheezy machine (Samba 3.6.6) to my freshly made backports AD (Samba 4.1.7). This is what I see: root at samba4:/# net ads join -U Administrator at AD.MICROSULT.DE Enter Administrator at AD.MICROSULT.DE's password: Using short domain name -- AD Joined 'SAMBA4' to

Well, seems like I hit every mudhole that could be on the way ... root at samba4:/# getent passwd | grep mgr mgr:*:10000:10000:Lars LH. Hanke:/home/AD/mgr:/bin/bash root at samba4:/# ldapsearch -LLL -D "CN=Administrator,CN=Users,DC=ad,DC=microsult,DC=de" -x -W '(uid=mgr)' uid uidNumber gidNumber sAMAccountName name gecos Enter LDAP Password: dn: CN=Lars LH.

On 29/12/14 16:25, support at remsnet.de wrote: > Hello , > > review bind9 options ... > >>> Dec 22 12:25:55 verdandi named[18534]: starting BIND 9.9.5-7-Debian -u >>> bind -4 >>> Dec 22 12:25:55 verdandi named[18534]: built with '--prefix=/usr' >>> '--mandir=/usr/share/man' '--infodir=/usr/share/info' >>>

Hello , review bind9 options ... >> Dec 22 12:25:55 verdandi named[18534]: starting BIND 9.9.5-7-Debian -u >> bind -4 >> Dec 22 12:25:55 verdandi named[18534]: built with '--prefix=/usr' >> '--mandir=/usr/share/man' '--infodir=/usr/share/info' >> '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads'

Don't know whether this is known or has been fixed, already. I see a reproducible crash of samba-tool when querying DNS (DLZ setup). I have two different VMs. One called samba, which is the AD DC and another called samba4, which is my toy for client setup. Host samba4 cannot be resolved by DNS and it failed to add to the zone during the join - but this is a different issue. root at

On 29/12/14 17:32, support at remsnet.de wrote: > Dear Rowland , > > Just keep in mind that the Debian RPI maintated by rasperry.org PI fellows and _not_ mainly by the Mainsteam debian > pkg maintainers, and ways behind the main distro - allmost. > >> Even though there is no mention of dlopen, samba_dlz works. >> > yes/no ->> its not displaying the DLZ file

If I query the AD DC I see: root at samba4:/# ldapsearch -H ldap://samba.ad.microsult.de -Y GSSAPI '(sAMAccountName=mgr)' SASL/GSSAPI authentication started SASL username: Administrator at AD.MICROSULT.DE SASL SSF: 56 SASL data security layer installed. I would like to see SASL SSF: 112. Does anyone know whether and where this can be configured? Regards, - lars.