Is there a way to retrive all the users who are enrolled in PHS (password hash synchronization) using Graph API or some other.
With the help of below command , we can find out whether Password Hash Synchronization is enabled for the Azure AD Users:https://learn.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-password-hash-synchronization#run-the-diagnostics-cmdlet-2
Invoke-ADSyncDiagnostics -PasswordSync
You can also check this document for troubleshooting task: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-password-hash-synchronization#understand-the-results-of-the-troubleshooting-task
Related
Azure ADFS is using a method to hash the sub claim of a JWT when using their oAuth2.0 capabilities as an IDP server.
The hash is made of the client id and a unique user identifier - I would like to recreate that hashing logic but can't find anywhere on Azure documentation that says how this hash logic works or if there is a way to unhash it from Azure / have it sent unhashed or any other suggestion that helps me be able to get this value on the front-end.
I would like to customize the password policy for my B2C Custom Login Flow. I can see how to change things like password length etc (see Password Polices)
But I also want to prevent the user from using any of the last 8 passwords. How would I do this?
This capability is currently not supported in Azure AD B2C.
Here is the feedback, please go and upvote this.
The best you can do with built in functions is: https://github.com/azure-ad-b2c/samples/tree/master/policies/password-reset-not-last-password
For more than last password history, the only workaround is to store the hashes yourself and use a REST API to examine the hash against the new password being provided. Something that we dont recommend doing, and rather using better techniques such as MFA.
In my application users can sign up in 3 different ways:
-Using their email and a password
-Using their Google account
-Using their Facebook account
I ask for their password to the users who signed up using their email and a password, when they want to delete their account in my application, in order to provide a better security so that a person who finds my application opened in a shared computer can not delete that account if he does not know the user's password.
I want to know what would be the secure approach to follow when a user who signed up using a Google/Facebook account wants to delete his account.
Does OWASP have a guide about that?
Would it be secure to send that user a link with a token valid for one hour (same thing we do to reset password for a user who signed up using its email and a password when he forgets his password and wants to sign in)?
You seem to be concerned about an attack scenario where a malicious actor has control of the user's Google or FB account. There's no difference in attack surface and security posture of a "delete" function in your app between this scenario and the scenario where the attacker knows the email/password of a user who signed up directly with you. The probability of an attacker taking over a Google or FB account is a lot lower than the probability of taking over a user account on an average web app. (Your web app might be super secure and way above average..or not).
We would say your priorities should be reversed - doing a more thorough delete confirmation on users who signed up directly with you is a better idea.
just trying to get my head around password synchronisation. In Windows Azure Active Directory Store DB the password will be matched to AD FS by which method? I getting a lot of reading about tokens and protocols, but is there anything else I have to aware of?
It's just general before I can dive deeper in synchronisation.
Thank you
It's done via AAD Connect. If you tick "password sync.", the password in AD (which is already hashed) is hashed again and propagated up to AAD.
Note that AAD doesn't use a "traditional DB". It uses a graph structure.
EDIT: (summary): I'm looking first for a way to have a custom, user-specific attribute passed to us as part of the ADFS signon; if that's reasonable, I'll dig into how to secure it.
EDIT: (clarification): I don't want to pass something through AD at time of login -- if the user has to enter their password and then authenticate again against AD, they're going to end up with confusing, mis-matching passwords. Instead I want registration with us to go like this:
user enters details (email, etc)
we generate a long random string, encrypt it, then provide that as part of a unique id to the client's AD
Then at each login:
We redirect the user to the client's AD for auth
Once the user is authorized, they're redirected back to us with user & claim info
That info includes the unique ID we generated -- so we extract a user ID and decrypt the password from that.
This would be lower security than we normally offer, but it's the best I can imagine if AD is involved. Is this possible?
Long version: A customer is asking that we add support for single sign-on to our web application, implementing Microsoft ADFS (Active Directory Federated Services).
The problem is that we rely on the user's password to decrypt their record; their private key is encrypted with their password, so we can't access their record without the password.
I've been digging into the documentation, e.g., http://msdn.microsoft.com/en-us/library/bb897402.aspx -- but currently I don't see way to securely manage some kind of secret encryption key using AD FS.
It wouldn't have to be the password itself, of course -- we implemented OAuth2 by generating random access tokens that have the same properties as a password (can be used to decrypt the user's record)... but an incoming, authenticated user needs to come with some kind of secure, private token.
Any guidance much appreciated!
If you are using ADFS 2.0, you can customize the pages.
So you could e.g. take the password, mangle it, write it to AD before invoking the SignIn and then have a claims rule that passes this. Then reverse the process in your application.
Note - I'm not suggesting that this is a "good" solution - just an example of what you can do.
Obviously security needs to be paramount!
Well there is Two ways to get your problem solved.
Customize the ADFS SignOn page(you should anyways take a backup) to create a form that receives users password. It is an webforms aspx page so you should have no trouble doing it. From there you must build your own STS to issue claims to ADFS so that ADFS can in turn pass these to your relying party. Map the custom STS as attribute store to the ADFS
You are just doing things wrong by taking security in your hand. ADFS uses HTTPS for transport level security and secure encryption with SAML 2.0 to handle your information, so another encryption would be no-brainer.
let me know which way you like going