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 grant those permissions in samba? Microsoft says (https://support.microsoft.com/en-us/help/303972/how-to-grant-the-replicating-directory-changes-permission-for-the-micr) to use "Active Directory Users and Computers snap-in", but we are not using those tools to manage our samba AD. MJ
Andrew Bartlett
2020-Oct-16 03:48 UTC
[Samba] azure ad provisioning | password hashes sync
On Thu, 2020-10-15 at 12:19 +0200, mj via samba wrote:> 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 grant those permissions in samba? > > Microsoft says > ( > https://support.microsoft.com/en-us/help/303972/how-to-grant-the-replicating-directory-changes-permission-for-the-micr > ) > to use "Active Directory Users and Computers snap-in", but we are > not > using those tools to manage our samba AD.This comes down to an ACL on the root of each partition if I recall, expressed most helpfully in SDDL. I've had a number of folks approach me at Catalyst to ask about this, but sadly all, when advised, decided to just use pass-though authentication rather than dig into this properly. 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: - the level 10 logs of the GetNCChanges call *only* (do read the logs and send just the packet dump of the GetNCChanges that fails). - a packet capture taken from the server - the traceback shown by the tool (those reporting it to me recently say the sync tool on windows shows tracebacks). Remember, that unlike the group sync (which is LDAP), the password sync is DRSUAPI over RPC, specifically a GetNCChanges call, as that is what is required to read passwords. I don't think the fix will be hard, but as nobody has written a test that matches the AD Sync behaviour, it has clearly been broken (or the tool changed). I've not read any current success stories. I hope this helps, Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Development and Support, Catalyst IT - Expert Open Source Solutions https://catalyst.net.nz/services/samba
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 an NT_STATUS_INTERNAL_ERROR, as soon as I start the AzureSync client:> [2020/10/16 13:43:47.319253, 1, pid=25360, effective(0, 0), real(0, 0), class=rpc_parse] ../../librpc/ndr/ndr.c:433(ndr_print_debug) > &tcon_blob: struct smbXsrv_tconB > version : SMBXSRV_VERSION_0 (0) > reserved : 0x00000000 (0) > info : union smbXsrv_tconU(case 0) > info0 : * > info0: struct smbXsrv_tcon > table : * > db_rec : NULL > local_id : 0x82a5e93e (2191911230) > global : * > global: struct smbXsrv_tcon_global0 > db_rec : NULL > tcon_global_id : 0x82a5e93e (2191911230) > tcon_wire_id : 0x82a5e93e (2191911230) > server_id: struct server_id > pid : 0x0000000000006310 (25360) > task_id : 0x00000000 (0) > vnn : 0xffffffff (4294967295) > unique_id : 0x015078ee87970d64 (94708558047153508) > creation_time : Fri Oct 16 01:43:47 PM 2020 CEST > share_name : NULL > encryption_flags : 0x00 (0) > 0: SMBXSRV_ENCRYPTION_REQUIRED > 0: SMBXSRV_ENCRYPTION_DESIRED > 0: SMBXSRV_PROCESSED_ENCRYPTED_PACKET > 0: SMBXSRV_PROCESSED_UNENCRYPTED_PACKET > session_global_id : 0x00000000 (0) > signing_flags : 0x00 (0) > 0: SMBXSRV_SIGNING_REQUIRED > 0: SMBXSRV_PROCESSED_SIGNED_PACKET > 0: SMBXSRV_PROCESSED_UNSIGNED_PACKET > status : NT_STATUS_INTERNAL_ERROR > idle_time : Fri Oct 16 01:43:47 PM 2020 CEST > compat : NULL > [2020/10/16 13:43:47.320250, 3, pid=25360, effective(0, 0), real(0, 0)] ../../lib/util/access.c:371(allow_access) > Allowed connection from 192.x.y.z (192.x.y.z) > [2020/10/16 13:43:47.320326, 10, pid=25360, effective(0, 0), real(0, 0)] ../../source3/smbd/share_access.c:238(user_ok_token) > user_ok_token: share IPC$ is ok for unix user DOM\azuresyncadm > [2020/10/16 13:43:47.320412, 10, pid=25360, effective(0, 0), real(0, 0)] ../../source3/smbd/service.c:70(set_conn_connectpath) > set_conn_connectpath: service IPC$, connectpath = /tmp > [2020/10/16 13:43:47.320472, 3, pid=25360, effective(0, 0), real(0, 0)] ../../source3/smbd/service.c:631(make_connection_snum)Could it be that the error already happens before samba tries to do anything like GetNCChanges? (since the error above seems to appear in rpc_parse) Or do I need to setup other logging for GetNCChanges errors? (and if yes: how do I do that?) (this is how I acheved the log above: https://wiki.samba.org/index.php/Client_specific_logging Best, MJ