This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 56.00000000000001%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESJ%3C/text%3E%3C/svg%3E)
Hi,
The question is a repeat of
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/a3359bde-b08a-46f6-b5b0-ef4e50de663f/azure-ad-scim-provisioning-how-to-sync-passwords?forum=WindowsAzureAD
However, I have not seen a definitive answer to whether AD syncs the password thru SCIM. Sorry, 'AFAIK' is not definitive.
If not, what is the reasoning ? When other IDPs (say Okta) are allowing this, why not AD ?
A cloud-based identity and access management service for securing user authentication and resource access
Answer accepted by question author
It is not possible to sync passwords out of AAD via SCIM provisioning. Passwords are stored in AAD using one-way hashing/salting and the original plaintext value cannot be retrieved. Best practice is to federate with the application in question via a standard such as SAML 2.0 or Open ID Connect/OAuth 2.0.
@Sriharsha J
I just wanted to check in and see if you had any other questions or if you were able to resolve this issue?
If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.
----------
Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.
Thanks for the clarification Zollner.
I was wondering about the intent of non-support. Is it the security issue OR because of storing non-plaintext value ?
If it is due storing non-plaintext value, AD can send the salted+hashed value, salt and the hash function.
It's both. There are massive security concerns there, even with just sharing a salted/hashed value, which I don't believe is possible either.
For what it's worth, there is interest in the SCIM working group to publish a modern security best practices document which would contain suggestions including not using the password attribute for most scenarios. Given general sentiment in the security community, I don't expect provisioning passwords (either plaintext or the hashed/salted value) to ever become possible.
Take note, this is different than initially seeding a random redacted/nondisclosed password into an application because the user cannot be created without a value being provided, which may be supported by some of our on-premises provisioning flows.