search for: pilsbach

"--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: CN=NTDS Settings,CN=PRE01SVDEB03,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=pilsbacher,...

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 pilsbacher.at pre01svdeb02.pilsbacher.at Looking for DNS entry NS pilsbacher.at pre01svdeb02.pilsbacher.at as pilsbacher.at. need cache add: NS _msdcs.pilsbacher.a...

...rrected, 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. :-) Now look at all that fun: dc.pilsbacher.at entry has been magically created again, it seems: root at pre01svdeb02:~# samba_dnsupdate --verbose IPs: ['192.168.16.205'] Looking for DNS entry A dc.pilsbacher.at 192.168.16.205 as dc.pilsbacher.at. Looking for DNS entry A pilsbacher.at 192.168.16.205 as pilsbacher.at. Looking for...

...ap auth, pm me your config ;-) Ok, what you posted below. pre01svdeb03 : apt-get remove --purge --auroremove resolvconf Old dc: pre01svdeb02 : apt-get remove --purge --auroremove resolvconf Make these changes/verify them after the remove of resolvconf pre01svdeb03 /etc/resolv.conf search pilsbacher.at nameserver 192.168.16.206 nameserver 192.168.16.205 pre01svdeb02 /etc/resolv.conf search pilsbacher.at nameserver 192.168.16.206 nameserver 192.168.16.205 ^^ yes note that "NOT switching" the DC's. If want here the other DC first untill its all ok local on this server. Reboo...

...: apt-get remove --purge --auroremove resolvconf > > Old dc: pre01svdeb02 : apt-get remove --purge --auroremove > resolvconf > > > > Make these changes/verify them after the remove of resolvconf > > > > pre01svdeb03 > > /etc/resolv.conf > > search pilsbacher.at > > nameserver 192.168.16.206 > > nameserver 192.168.16.205 > > > > pre01svdeb02 > > /etc/resolv.conf > > search pilsbacher.at > > nameserver 192.168.16.206 > > nameserver 192.168.16.205 > > > > ^^ yes note that "NOT switching&...

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 ?

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 only? > > "reinstall samba" ? > > pls specify Ah, I understand this (correct me): mv FSMO-roles to...

...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 /pre01svdeb02 (old DC) ) : A 192.168.16.205 dc.pilsbacher.at <<< OLD NAME REPLY. DNS2 ( DC2 /pre01svdeb03 ) : A 192.168.16.206 pre01svdeb03.pilsbacher.at Both DNS replies the same on lookup A dc.pilsbacher.at to 192.168.16.205 But your PTR...

...via samba > Verzonden: woensdag 31 juli 2019 16:19 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] GPO issues - getting SYSVOL cleaned up again > > Am 31.07.19 um 16:08 schrieb Stefan G. Weichinger via samba: > > > Now look at all that fun: > > > > dc.pilsbacher.at entry has been magically created again, it seems: > > > > > > root at pre01svdeb02:~# samba_dnsupdate --verbose > > IPs: ['192.168.16.205'] > > Looking for DNS entry A dc.pilsbacher.at 192.168.16.205 as > dc.pilsbacher.at. > > > and it'...

Am 31.07.19 um 18:03 schrieb Stefan G. Weichinger via samba: > 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 only? >> >> "reinstall samba" ? >> >> pls specify > > Ah, I un...

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

...u fixed it > > I assume I face something similar > > > my 2 DCs seem to be out of sync for DNS I demoted and rejoined, and still see: ; TSIG error with server: tsig verify failure Failed nsupdate: 2 update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.pilsbacher.at pre01svdeb03.pilsbacher.at 389 Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.pilsbacher.at pre01svdeb03.pilsbacher.at 389 (add) Successfully obtained Kerberos ticket to DNS/pre01svdeb03.pilsbacher.at as PRE01SVDEB03$ Outgoing update query: ;; ->>HEADER...

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

...It ain't perfect yet, but I assume this is related to the computer > accounts and might be solved be rejoining these machines. > > I see stuff like: > > Aug 01 10:04:38 pre01svdeb02 samba[17958]: > task[dcesrv][17958]: Failed > to modify SPNs on > CN=ROHRHOFER-PC,OU=Pilsbacher-Computer,DC=pilsbacher,DC=at: acl: spn > validation failed for spn[TERMSRV/ROHRHOFER-PC.mydomain.at] > uac[0x1000] > account[ROHRHOFER-PC$] hostname[ROHRHOFER-PC.BUERO] nbname[BUERO] > ntds[(null)] forest[mydomain.at] domain[mydomain.at] > In this case, you can check for the righ...

Hai, I just renamed that file to .old on one of my DC's. systemctl stop samba-ad-dc && systemctl start samba-ad-dc New file is created yes, so this looks like the solution. Stefan, once this is done. Verify again the servers in : Sites - Default-First-Site-Name - Servers Windows DNS tool, zone your.dom.tld. For the A IN-ARPA .. For the PTR. _msdcs.your.dom.tld. For GUIDs.

...d-dc.service Jul 31 13:42:20 pre01svdeb02 samba[32029]: task[dnsupdate][32029]: [2019/07/31 13:42:20.259104, 0] ../lib/util/util_runcmd.c:327(samba_runcmd_io_handler) Jul 31 13:42:20 pre01svdeb02 samba[32029]: task[dnsupdate][32029]: /usr/sbin/samba_dnsupdate: couldn't get address for 'dc.pilsbacher.at': not found Jul 31 13:42:20 pre01svdeb02 samba[32029]: task[dnsupdate][32029]: [2019/07/31 13:42:20.295584, 0] ../lib/util/util_runcmd.c:327(samba_runcmd_io_handler) Jul 31 13:42:20 pre01svdeb02 samba[32029]: task[dnsupdate][32029]: /usr/sbin/samba_dnsupdate: couldn't get address for...

Am 2017-07-11 um 09:34 schrieb Stefan G. Weichinger via samba: > [2017/07/11 09:31:17.790046, 2] > ../source4/dns_server/dns_query.c:1019(dns_server_process_query_send) > Not authoritative for 'SERVER', forwarding > [2017/07/11 09:31:17.826966, 2] > ../source4/dns_server/dns_query.c:1019(dns_server_process_query_send) > Not authoritative for 'SERVER',

...to wait now? > > loglevel 4 on DC2 > > > [2019/03/13 14:38:55.729004, 3] > ../source4/dsdb/repl/drepl_service.c:206(_drepl_schedule_replication) > _drepl_schedule_replication: forcing sync of partition > (61081d43-e55d-4791-9d4c-e87f036a8772, > DC=DomainDnsZones,DC=pilsbacher,DC=at, > e5922d4b-9bf0-4c79-b256-ff5f75a3e4f4._msdcs.mytld.at) > > > but no progress > > - > > I let my fingers off it for now ... new user(s) needed there > next week. > > > -- > To unsubscribe from this list go to the following URL and read the &gt...

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

...tbios name = DC02 printcap name = /dev/null realm = MYDOM.AT server role = active directory domain controller template shell = /bin/bash time server = Yes usershare path = workgroup = BUERO sdb:schema update allowed = no idmap_ldb:use rfc2307 = yes [netlogon] path = /var/lib/samba/sysvol/pilsbacher.at/scripts read only = No acl_xattr:ignore system acls = Yes [sysvol] path = /var/lib/samba/sysvol read only = No acl_xattr:ignore system acls = Yes [rsnapshots] path = /mnt/rsnapshots valid users = @rsnapshots ---- AD works for the Win10 clients, no alerts so far. wbinfo -u and -g sh...