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.
Related
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
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 brief: can I give my Azure application access to a limited set of mailboxes while still using the Client Credentials Flow (no signed in user)?
More detail
In Azure I have an app-only type application; by this I mean I will authenticate to it using the Client Credentials Flow which means there is no signed-in user present.
Once authenticated I will acquire a token to access Microsoft Graph. I want to use Graph to access a limited set of Office365 mailboxes.
As far as I understand, I can use the admin-only Mail.Read permission scope for this, but this gives my application access to every user mailbox. I would prefer to avoid such broad access.
I think if I used delegated permissions instead, I could use the Mail.Read.Shared scope which would allow my application to read mailboxes that are shared with the signed in user, but then I can't use the Client Credentials Flow because I need to sign in a user, which is what I'm trying to avoid. This is an application which doesn't logically run in the context of a user. (The mailboxes I want to read are all shared, they aren't user mailboxes)
I'm a total Azure noob so I hope this makes sense.
Is this question in the right place?
I'm not sure. On the one hand, there are about 100 azure question in softwareengineering, but there are over 54k on SO, and that's not including sub tags.
On the other hand, I haven't included anything about programming in this question, although it is certainly a programming issue for me, insofar as I have to write the code to authenticate with Azure, get the token, and then access the Graph API, and the answer to this question will probably influence how I go about that. FWIW, here's how I'm currently authenticating and getting a token in C#:
var authority = $"https://login.microsoftonline.com/{tenant}/v2.0";
var authContext = new AuthenticationContext(authority);
var clientCredential = new ClientCredential(clientId, secret);
var token = authContext.AcquireTokenAsync("https://graph.microsoft.com/", clientCredential).Result.AccessToken;
Although I do plan to change that to use a certificate rather than a secret.
If there is a better place for my question (whether stackexchange or other), please do let me know.
App permissions are always organization-wide. The good thing for them is that using Client Creds is relatively simple and reliable. Revoking them would require deleting the role assignment or deleting the service principal entirely. But the bad side is that you cannot limit what it can access.
With delegated permissions, you could make a small web front-end, which allows users to login and give permissions to read their mail.
Your app can then store the user's refresh token securely and use that to access their mail whenever.
The good side is that this limits access to only those users who explicitly give permissions.
The bad side is this requires more work and is not as reliable, since refresh tokens get revoked if a user's password changes (for example).
And you must make sure you store the new refresh token you get when acquiring a token with the older refresh token.
TL;DR: There is no "right" answer to this. Both approaches have pros and cons, and neither is perfect. If your app cannot handle losing access for a while, then you must use app permissions.
I'm trying to understand conceptually and practically how to perform an oauth2 with openID-connect flow in my web-api application, utilising Azure AD.
Importantly, when a request is made to the API I want to know who made the request.
My current understanding is :-
My client would detect that the user isn't logged in and redirect to a sign-in.
The user would provide their credentials, and be redirected back to the client, along with an oauth2 token.
This token would be supplied to web-api endpoints for any requests.
This is where it gets murky for me.
How exactly do I use this token to authorize access to a particular resource, determine who is accessing the resource, and what is the mechanism that does so?
I'm sort of assuming that I would need to reuse the token to make a call to the Azure AD user endpoint - if the token was indeed valid, the AD endpoint would return the users details - thereby providing some means of determining that the token is valid and providing details on the users identity. Authorizing access to a resource could be done through membership of groups in Azure AD.
BUT ...
I can only assume this a solved problem, and have noticed use of OWIN middleware as per this example
https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
But I'm still rather unsure as to what is exactly going on.
The service makes mention of scopes and claims, but I don't understand where these are derived from (I assume from a token supplied by the client, but not sure). The service must be receiving identity information in the call.
Which brings me to two points, for this to be secure -
The token provided in call to the service would need to be secured in transmission (hence the use of HTTPS) - to prevent MITM.
The token would need to be signed some how - I guess by using client secret or something - to prevent information in the token being spoofed.
Can someone help me clear up this muddled mess?
In particular -
How is the identity of the API caller determined - is identity determined from a call in the client or the server?
How to limit access to some endpoints of the API based on a user role?
What do I do to practically achieve this by building on existing middleware and libraries available to me?
Disclaimer: This will not be a comprehensive answer. It is off the top of my head.
OpenID Connect provides an identity layer on top of OAuth. In your case, Active Directory provides the authentication and sends back an access_token. The access token represents a user that AD has authenticated. If your doing OpenID Connect, then AD will also send an id_token, which may contain additional identity information (such as birthday, avatar, and whatever else AD exposes.)
Neither OpenID Connect nor Active Directory have anything to do with the the roles that your app assigns to a user; roles are entirely the bailiwick of your app. You assign user roles just like you normally would; you assign them to the nameid though instead of to an email address or username. Your app no longer has to authenticate the user but it does need to assign roles to the nameid.
How is the identity of the API caller determined - is identity determined from a call in the client or the server?
The identity is embedded in the access_token that AD includes in its response. This token will have a nameid in it that your app can associate with a user and role. The nameid is like an email address, username, or other uniqueID that your app uses to recognize the user.
How to limit access to some endpoints of the API based on a user role?
You choose. When your app receives a request with a particular access_token, that token will be associated with a particular user via its nameid, and you can assign whatever roles and rights to that user. Basically, associate roles with a nameid.
What do I do to practically achieve this by building on existing middleware and libraries available to me?
There is an unfinished demo here, though it doesn't use Active Directory as the provider, instead, it uses an internal provider. For the demo, the username is shaun and password is Testing123!. The source code is here.
Here is the link to the source of another demo, though again, it doesn't use Active Directory as the provider, instead, it uses Twitter.
The nice thing about OAuth and OpenID Connect is that we can use whatever identity provider we want, so you can adapt the demos to use Active Directory.
Apart from question #1 (the identity is verified on the service side) all your question are very open ended and would require a super long answer.
I would recommend reading https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ - it is a good introduction to the flows underlying many of the modern authentication cenarios, including the web API one you are focusing on.
Once you have read that, you will find a complete set of samples in https://azure.microsoft.com/en-us/documentation/articles/active-directory-code-samples/ - in particular, I suggest studying the web API and thru authorization one to find guidance on the 3 questions you listed. HTH!
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