similar to: Azure AD Connect and replication issues

Hi Michal, Seems we are doing similar things at the moment: getting samba to work with azure AD. We also see the high CPU usage on the DC that the Azure AD Connect server connected to. Between 70 - 100 percent in our case. We are not seeing any replication issues after azure AD Connect, and I have a script that automatically checks replication every few minutes. I was the one reporting the

just small update: - idfix tool (Directory Synchronization Error Remediation Tool / https://github.com/microsoft/idfix) shows just small issues like empty/missing displayName attrib in some of objects which I have corrected and no more issues present at all. - no errors from AAD connect event viewer: final log message is "Scheduler::SchedulerThreadMain : Completed configured scheduler

ups, seems pictures (attachments in general) are not accepted here, screen (graph) is available here: https://i.postimg.cc/xCk6k038/image-2020-10-21-190940.png On 10/21/2020 6:00 PM, Michal Bruncko wrote: > hello > > our AD domain is hosted by two samba AD domain controllers version 4.12.6 > - replication between controllers is fine, no problems. > - no schema errors. > - no

hello mj we are school - we are syncing approx 500 users and several groups. we use pass-through authentication because AAD authentication was not working (that time we used samba 4.8.12, but since moving to 4.12 I didnt tested this), we have (as recommended) one AAD connector plus two authentication agents deployed in our environment. the thing what I dont understand is the amount of data

hello all just to summarize this topic for anybody else. after some time spent with tshooting there seems is a sufficient workaround for this issue: disable "sync of password hashes" option within Azure AD connect tool. with disabling this option all three issues (CPU/Bandwidth utilization/replication logs) are gone! seems that for now the only working option for samba and Azure

Hi Michal, Thanks for updating, I can confirm your findings on our site. Pass-through auth works nicely here as well. However, when reading the ticket, we understand that Ralph B?hme claims that password-hashes should also work, after making the sync account MSOL_604447e... a member of "domain admins". (instead of keeping the default rights that are granted by the installer, which

Hi all, We would appreciate some input here. Not sure where to look... We have three AD DCs, all running samba 4.5.10, and since a few days, the samba DCs are getting stuck regularly, at ramdon times. Happens to all three of them, randomly, and currently it is happening up to a few times per day..! Must be some common cause. For the rest, the systems appear fine, enough diskspace, nothing

Hi James, Thanks for the quick reply. On 10/09/2017 08:52 PM, lingpanda101 via samba wrote: > You should be able to fix the 'replPropertyMetaData' errors with; > > samba-tool dbcheck --cross-ncs --fix --yes > 'fix_replmetadata_unsorted_attid' Yep, worked great! Fixed all of those replPropertyMetaData errors! :-) > The highwatermark doesn't necessarily

Hi all, James, After following James' suggestions fixing the several dbcheck errors, and having observed things for a few days, I'd like to update this issue, and hope for some new input again. :-) Summary: three DCs, all three running Version 4.5.10-SerNet-Debian-16.wheezy, samba-tool dbcheck --cross-ncs reports no errors, except for two (supposedly innocent) dangling forward links

Hi, Reading the microsoft troubleshooting guide, it seems that password hash sync issues can be caused by: > The Active Directory account used by Azure AD Connect to communicate > with on-premises Active Directory is not granted Replicate Directory > Changes and Replicate Directory Changes All permissions, which are > required for password synchronization. How to verify existance or

Hi all, An update. On 10/26/20 10:24 PM, Andrew Bartlett wrote: > The fact that there is a viable workaround (pass-though authentication) > also seems to be making this harder to fix - because it remains an > annoyance, not a deal-breaker. Today I tried again with these ingredients: - fresh azure tenant - fresh installed AD (samba 4.12.8 sernet) - an azure "custom domain

I believe a schema change on a Windows DC (2008rc) has broken replication with our S4 DCs. Anyone have any tips or pointers to resolve this? I have three S4 DCs [CentOS6] and one Windows 2008R2 DC. The Windows 2008R2 DC has the schema master FSMO, and I believe the Exchange schema was added. I am willing to pay US dollars to get this issue resolved. I need the replication restored, the

Hello, I upgrade the schema for our main ADDC and everything works properly, but the member DC (DC to an Existing AD) fails. Both servers are in version 4.10.2 Distro: Debian 9.8 *Main ADDC:* [2019/04/16 15:43:03.814846, 0] ../../source4/rpc_server/drsuapi/getncchanges.c:2919(dcesrv_drsuapi_DsGetNCChanges) ../../source4/rpc_server/drsuapi/getncchanges.c:2919: DsGetNCChanges 2nd replication

Hi Denis Thanks for your response without your crystal ball. I have increased the log level =9 dns:0 on both the servers. It replicates successfully by manually running the command samba-tool drs replicate SERVER2 SERVER1 dc=iumnet,dc=edu,dc=na --full-sync but it is still failing when I check from the samba-tool drs showrepl Also I run samba-tool dbcheck --cross-ncs --fix on both the servers

Hi, On 10/16/20 5:48 AM, Andrew Bartlett wrote: > What I asked them for, and (because we have worked together before) I'm > confident you can get is, correlated by a high-resolution timestamp: I hope someone here can help me a little bit, doing the above. I have a level 10 log from the samba DC, however, it shows nothing like "GetNCChanges" anywhere. It does however show

HI ! I demote dc "same" name and rename dc, but same IP adresss. But erro persiste... DC "new name" May  9 15:34:39 dcXXX-NEW samba[12278]:   UpdateRefs failed with WERR_DS_DRA_ACCESS_DENIED/NT code 0xc0002105 for 37ba1799-307a-49ef-a6df-3657da7c4c98._msdcs.XXXX DC=DomainDnsZones,DC=XXX,DC=XXX,DC=XXX,DC=XX 37ba1799-307a-49ef-a6df-3657da7c4c98 = dcXXX-NEW Any  ideia ?

Thanks Rowland and Garming for your help!! How about "another DC", or 'a second DC' ? Ok. Got it! :D Alternatively, re-joining the domain controller (or joining a new DC and > demoting the old one) probably works because I believe there is code to > handle this case. I re-joined (remove secrets.tdb and .lbd, copy idmap from existing DC...) and now works properly!

Hi, i have message in syslog, is problem ? :-/ May  9 01:21:48 dcXXX samba[16414]: [2018/05/09 01:21:48.965568,  0] ../source4/rpc_server/drsuapi/getncchanges.c:1657(dcesrv_drsuapi_DsGetNCChanges) May  9 01:21:48 dcXX samba[16414]: ../source4/rpc_server/drsuapi/getncchanges.c:1657: DsGetNCChanges 2nd replication on different DN CN=Schema,CN=Configuration,DC=XXX,DC=XXX,DC=com,DC=br

Hello, Thanks for the feedback Garming!!! 👍 On Wed, Apr 17, 2019 at 12:35 AM Garming Sam <garming at catalyst.net.nz> wrote: > Hi, > > While I think we have most of the 2012 schema problems under control > now, there's still quite a bit of work to get the functional level > things working. In order to actually raise the level, we still need to > implement a number of

On 10/12/2017 3:17 AM, mj wrote: > Hi all, James, > > After following James' suggestions fixing the several dbcheck errors, > and having observed things for a few days, I'd like to update this > issue, and hope for some new input again. :-) > > Summary: three DCs, all three running Version > 4.5.10-SerNet-Debian-16.wheezy, samba-tool dbcheck --cross-ncs reports