similar to: GPO issues - getting SYSVOL cleaned up again

"--seize" helped: root at pre01svdeb03:~# samba-tool fsmo show SchemaMasterRole owner: CN=NTDS Settings,CN=PRE01SVDEB03,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=pilsbacher,DC=at InfrastructureMasterRole owner: CN=NTDS Settings,CN=PRE01SVDEB03,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=pilsbacher,DC=at RidAllocationMasterRole owner:

On 31/07/2019 12:04, Stefan G. Weichinger via samba wrote: > Am 31.07.19 um 12:50 schrieb Rowland penny via samba: >> On 31/07/2019 11:40, Stefan G. Weichinger via samba wrote: >>> Am 31.07.19 um 12:32 schrieb Rowland penny via samba: >>>> On 31/07/2019 11:22, Stefan G. Weichinger via samba wrote: >>>>> "dc" was the old name a few years ago

> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Stefan G. Weichinger via samba > Verzonden: vrijdag 12 juli 2019 10:24 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] GPO infrastructure? -> 4.8.x to 4.9.x > > Am 10.07.19 um 08:40 schrieb Stefan G. Weichinger via samba: > > > more of this: > >

Am 31.07.19 um 15:59 schrieb L.P.H. van Belle via samba: > Ok, after that reboot > > ! Note, atm dont care about secrets.keytab (yet) > .. I was a bit ahead with things... > > One thing at a time, for the keytab to be corrected, you need a perfect correct working > A PTR CNAME GUIDs for the DC(3) first then we start thinking in kerberos corrections. > > Run

(oeps) this need to be in this mail also. Try : rgrep "dc.domain.at" /etc/* > -----Oorspronkelijk bericht----- > Van: L.P.H. van Belle > Verzonden: woensdag 31 juli 2019 12:17 > Aan: 'samba at lists.samba.org' > Onderwerp: RE: [Samba] GPO issues - getting SYSVOL cleaned up again > > Ok, on that server. > > This > >

Hai, And thanks for the other check i needed to know if the A record did exist. >> ldap1 CNAME pre01svdeb02 >> ldap2 CNAME pre01svdeb03 >sorry, typo -------------^ Yes i was expecting that. ;-) What i see, all SOA record and serialnr are same where is should be so thats ok. What i noticed is this part. dig a dc.pilsbacher.at @192.168.16.205/206 replies. DNS1 ( DC1

Am 31.07.19 um 13:37 schrieb L.P.H. van Belle via samba: > So if i understand correctly. > You removed : /var/lib/samba/private/dns_update_cache > > Stopped samba and started samba and you got the dns A for hostname DC back > in /var/lib/samba/private/dns_update_cache ?? Yes! repeated that once more now. Same result. > Hmm.. >> SOA contains

I forgot. dig a pre01svdeb02.pilsbacher.at @192.168.16.205 dig a pre01svdeb02.pilsbacher.at @192.168.16.206 Can you run these also for me. And there are no CNAMEs pointing to the AD-DCs ?

Progress: no more "dc" in rgrep on both servers PTR for the rejoined pre01svdeb02 is missing, so I assumed we need a dnsupdate: root at pre01svdeb02:~# samba_dnsupdate --verbose IPs: ['192.168.16.205'] need cache add: A pre01svdeb02.pilsbacher.at 192.168.16.205 Looking for DNS entry A pre01svdeb02.pilsbacher.at 192.168.16.205 as pre01svdeb02.pilsbacher.at. need cache add: NS

Then you might have hitted this bug. https://bugzilla.samba.org/show_bug.cgi?id=13969 Patch is to be tested atm. Greetz, Louis > -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Stefan G. Weichinger via samba > Verzonden: vrijdag 12 juli 2019 14:28 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] GPO

Am 31.07.19 um 17:54 schrieb Stefan G. Weichinger via samba: > Am 31.07.19 um 17:33 schrieb L.P.H. van Belle via samba: > >> Which is the DC with FSMO roles, if its DC1 then move them to pre01svdeb03.pilsbacher.at >> Remove/purge this DC and join clean again. ( no need to reinstall os etc. just samba ) > > What? > > uninstall samba? > or unjoin from domain

Am 31.07.19 um 10:47 schrieb L.P.H. van Belle via samba: > I pointed to that link becuase of the last message. >>> The OU the users were in required read permissions on the Authenticated Users security group! > Im guyessing this is what your problem is, i just dont know where in your AD. OK, that might be the case. So the step is "add/check ACLs on the SYSVOL-share for

I figured it out myself. The kerberos configuration on the old dc cobra was bad ? no clue why it worked at all until yesterday. After fixing it, testing with kinit, and restarting the dc processes it resumed replication. Joachim Von: Joachim Lindenberg <samba at lindenberg.one> Gesendet: Friday, 19 July 2019 16:54 An: samba at lists.samba.org Betreff: replication stuck? Until

Good morning Stefan. Your welkom. I see everything worked out now. Great !! Well done, you made it happen. :-) What i suggest now, at least these are the steps i always do to make sure the DC's are having a exact same setup. First, i clear all my logs and reboot one server. Wait 15-30 min, then go through all you logs, fix every warning/error. Make it perfect. Reboot again, repeat

On 10/12/15 14:00, Ole Traupe wrote: > > > Am 10.12.2015 um 14:38 schrieb Rowland penny: >> On 10/12/15 13:25, Ole Traupe wrote: >>> Is it possible that kdc server is always the SOA, at least if >>> derived from DNS and not specified *explicitly* in the krb5.conf? >>> >>> In my DNS-Manager console I find that >>> >>>

On 10/12/15 14:40, Ole Traupe wrote: > >>> However, my 2nd DC is not that new, I restarted it many times, just >>> again (samba service). No DNS records are created anywhere. >>> >>> If I go through the DNS console, in each and every container there >>> is some entry for the 1st DC, but none for the 2nd (except on the >>> top levels: FQDN

I installed a third DC today. Replication works find, but as systemctl status samba-ad-dc showed an error w.r.t. dnsupdate I was running samba_dnsupdate ?verbose. Below is the output. It looks like there are some missing DNS records, but what are potential causes of this error: dns_tkey_gssnegotiate: TKEY is unacceptable I already checked what?s listed @

Ok, after that reboot ! Note, atm dont care about secrets.keytab (yet) .. I was a bit ahead with things... One thing at a time, for the keytab to be corrected, you need a perfect correct working A PTR CNAME GUIDs for the DC(3) first then we start thinking in kerberos corrections. Run samba_dnsupdate --verbose ( on both DC's ) Post that output, ill have a look, and im getting a choco.

Am 31.07.19 um 12:19 schrieb L.P.H. van Belle via samba: > And check : > > rgrep "dc.domain.at" /var/lib/* There we are -> root at pre01svdeb03:~# rgrep "dc..at" /var/lib/* Binary file /var/lib/samba/private/sam.ldb.d/DC=,DC=AT.ldb matches Binary file /var/lib/samba/private/sam.ldb.d/CN=CONFIGURATION,DC=,DC=AT.ldb matches root at pre01svdeb02:~# rgrep

Am 04.01.2024 um 13:28 schrieb lists--- via samba: > Am 04.01.2024 um 12:36 schrieb Rowland Penny via samba: >> On Thu, 4 Jan 2024 12:12:57 +0100 >> lists--- via samba <samba at lists.samba.org> wrote: >> >>> Am 04.01.2024 um 11:55 schrieb Rowland Penny via samba: >>>> On Thu, 4 Jan 2024 11:19:17 +0100 >>>> lists--- via samba <samba at