[Samba] azure ad provisioning | password hashes sync
mj
lists at merit.unu.edu
Wed Oct 14 17:46:13 UTC 2020
Hi,
Meanwhile we have discovered this bug report:
https://bugzilla.samba.org/show_bug.cgi?id=10635
where Andrew is asking to test again with modern versions as a first
step towards a solution.
So I will start upgrading our DCs to latest in de coming period, to see
if that helps anything.
Strange also that the reporter of bug 10635 is seeing all kinds of error
messages logged in azure, and we don't see any, just green light and 'ok'.
Also nothing on the local on-prem domain member server, so I'm actually
unsure where exactly this is failing, I just know the accounts/groups
are all there, but I cannot logon azure with my samba AD credentials.
Strange enough there are also a few success reports of people syncing
the password on this mailinglist. (although the ones reporting failures
seem to be the majority)
Insights would be appreciated.
MJ
On 10/14/20 1:54 PM, mj via samba wrote:
> Hi,
>
> We are (again) looking at syncing our samba AD to the azure AD cloud.
>
> I installed a win2016 server domain member server and set it up for
> syncing, including password hashes, so users can login azure/O365 using
> their on-prem passwords.
>
> We're using microsoft's latest tech: the new "Azure AD Connect cloud
> provisioning". We made sure to check "password hash sync". Our users &
> groups are synced, and from azure's point of view, the sync has a green
> status 'healthy'. No errors logged.
>
> However, trying to logon on with the on-prem password does not work,
> with a 'wrong password' error in azure.
>
> We have made the on-prem samba account used for the synchrosisation
> member of "domain admins" and "enterprise admins", so I think
> permission-wise it should be in order.
>
> Reading this article:
> https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-password-hash-sync
>
> the required password hashes are "NTLM and Kerberos password hashes".
>
> I setup client specific logging on our DC for the Azure AD Sync server,
> and a grep for "password" on the generated logs:
>
>> passwordAttribute: pekList
>> passwordAttribute: msDS-ExecuteScriptPassword
>> passwordAttribute: clearTextPassword
>> passwordAttribute: userPassword
>> passwordAttribute: ntPwdHash
>> passwordAttribute: sambaNTPwdHistory
>> passwordAttribute: lmPwdHash
>> passwordAttribute: sambaLMPwdHistory
>> passwordAttribute: krb5key
>> passwordAttribute: dBCSPwd
>> passwordAttribute: unicodePwd
>> passwordAttribute: ntPwdHistory
>> passwordAttribute: lmPwdHistory
>> passwordAttribute: supplementalCredentials
>> passwordAttribute: priorValue
>> passwordAttribute: currentValue
>> passwordAttribute: trustAuthOutgoing
>> passwordAttribute: trustAuthIncoming
>> passwordAttribute: initialAuthOutgoing
>> passwordAttribute: initialAuthIncoming
>> passwordAttribute: pekList
>> passwordAttribute: msDS-ExecuteScriptPassword
>> 88488634-868425949-572>;CN=Denied RODC Password Replication
>> Group,CN=Users,DC
>> dn:
>> <GUID=9bec2aa0-99bf-479d-81e7-7447eee4b155>;<SID=S-1-5-21-90839350-988488634-868425949-572>;CN=Denied
>> RODC Password Replication Group,CN=Users,DC=samba,DC=company,DC=com
>> 88488634-868425949-572>;CN=Denied RODC Password Replication
>> Group,CN=Users,DC
>> [2020/10/14 13:36:54.288696, 3, pid=32634, effective(0, 0), real(0,
>> 0)] ../../source3/smbd/password.c:140(register_homes_share)
>> dsdb_password_audit: 10
>> dsdb_password_json_audit: 10
>> last_password_change : Thu Mar
>> 12 09:00:04 PM 2020 CET
>> allow_password_change : Thu Mar
>> 12 09:00:04 PM 2020 CET
>> force_password_change : Thu Sep
>> 14 04:48:05 AM 30828 CEST
>> bad_password_count : 0x0000 (0)
>> last_password_change :
>> Thu Mar 12 09:00:04 PM 2020 CET
>> allow_password_change :
>> Thu Mar 12 09:00:04 PM 2020 CET
>> force_password_change :
>> Thu Sep 14 04:48:05 AM 30828 CEST
>> bad_password_count :
>> 0x0000 (0)
>> last_password_change : Thu Mar
>> 12 09:00:04 PM 2020 CET
>> allow_password_change : Thu Mar
>> 12 09:00:04 PM 2020 CET
>> force_password_change : Thu Sep
>> 14 04:48:05 AM 30828 CEST
>> bad_password_count : 0x0000 (0)
>> last_password_change :
>> Thu Mar 12 09:00:04 PM 2020 CET
>> allow_password_change :
>> Thu Mar 12 09:00:04 PM 2020 CET
>> force_password_change :
>> Thu Sep 14 04:48:05 AM 30828 CEST
>> bad_password_count :
>> 0x0000 (0)
>> passwordAttribute: clearTextPassword
>> passwordAttribute: userPassword
>> passwordAttribute: ntPwdHash
>> passwordAttribute: sambaNTPwdHistory
>> passwordAttribute: lmPwdHash
>> passwordAttribute: sambaLMPwdHistory
>> passwordAttribute: krb5key
>> passwordAttribute: dBCSPwd
>> passwordAttribute: unicodePwd
>> passwordAttribute: ntPwdHistory
>> passwordAttribute: lmPwdHistory
>> passwordAttribute: supplementalCredentials
>> passwordAttribute: priorValue
>> passwordAttribute: currentValue
>> passwordAttribute: trustAuthOutgoing
>> passwordAttribute: trustAuthIncoming
>> passwordAttribute: initialAuthOutgoing
>> passwordAttribute: initialAuthIncoming
>> passwordAttribute: pekList
>> passwordAttribute: msDS-ExecuteScriptPassword
>> last_password_change : Thu
>> Mar 12 09:00:04 PM 2020 CET
>> allow_password_change : Thu
>> Mar 12 09:00:04 PM 2020 CET
>> force_password_change : Thu
>> Sep 14 04:48:05 AM 30828 CEST
>> bad_password_count :
>> 0x0000 (0)
>> last_password_change : Thu
>> Mar 12 09:00:04 PM 2020 CET
>> allow_password_change : Thu
>> Mar 12 09:00:04 PM 2020 CET
>> force_password_change : Thu
>> Sep 14 04:48:05 AM 30828 CEST
>> bad_password_count :
>> 0x0000 (0)
>>
>
> I have read some success-stories here on the list, but also some
> questions and uncertainties, and I'm not sure what the situation is,
> with samba AD and Azure AD sync.
>
> Is this supposed to work? Our DC's are still running samba 4.10.17, we
> intent to upgrade them. Would that have any effect here..?
>
> Anyone here with suggestions or ideas..?
>
> Regards and thanks!
>
> MJ
>
More information about the samba
mailing list