Say I sign into my site with ACS. Then close the browser, then reopen the site... it asks me to sign-in again. I would like it so it doesn't ask me to signin for a week or so after I authenticate with ACS the first time. How does one go about accomplishing this?
You don't authenticate against ACS. ACS is an intermediary between your app and an identity provider (e.g. LiveID, Google, Facebook, etc).
If you set "remember me" with any of these sites (and if they support it), then you will not be asked for username/password the second time.
Add the following attributes, this will persist the cookie with an extended lifetime.
<wsFederation ... persistentCookiesOnPassiveRedirects="true">
<CookieHandler ... persistentSessionLifetime="60"/>
...
</>
Pay attention, that the description about persistentSessionLifetime in MSDN is not true. For example, if you set it to 1.6:13:45.0, the cookie will expire after 30 hours (1 day + 6 hours) 13 minutes and 45 seconds +/- the maximumClockSkew from <identityConfiguration>. So the description from MSDN should be like the one from TimeSpan: [-]d.hh:mm:ss.ff. I hope Microsoft changes the wrong description.
Related
Has Microsoft changed the expiration date for Client secrets to be max 2 years? It is not possible to select "Never" anymore?
I just ran into this myself. You can set add a credential using Powershell which is more than 2 years. So I'm guessing it's a UI limitation.
$startDate = Get-Date
$endDate = $startDate.AddYears(98)
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId b09d3e1b-417d-425c-be05-9e46943d7207 -StartDate $startDate -EndDate $endDate
Has Microsoft changed the expiration date for Client secrets to be max
2 years? It is not possible to select "Never" anymore?
That's correct. The new expiration age for the client secret can be 2 years maximum.
As of February 2022 it isn't possible anymore:
https://devblogs.microsoft.com/microsoft365dev/client-secret-expiration-now-limited-to-a-maximum-of-two-years/
Looks like we got an official answer from Microsoft's team at Jun 08, 2021, according to this discussion: https://learn.microsoft.com/en-us/answers/questions/422538/future-plans-of-microsoft-with-the-maximum-expirat.html
This was the final answer from their engineering team:
There are plans to limit lifetimes of the secret administratively. However, there are no current timelines or ETAs of when this will happen. Removing the UX option to have never expiring secrets is a first step of that process (you can still create secrets that never expire with PowerShell, AZ CLI and Graph API).
So, I understood that, for a while, I can use PowerShell's method suggested by Daniel in the accepted answer above.
However, we cannot rely on this forever because sooner or later the 'never' option may disappear completely if Microsoft's plans materialize. I hope it doesn't in this case. As some have said, I also foresee expiration problems in the coming years because of this limitation.
You can set the date through Azure Built in CLI.
Open the Azure CLI in the browser. Then this command below. Note: If you don't pass a password, this will reset your existing password! The end-date is whatever you want it to be:
az ad sp credential reset --name {name of your AD app} --end-date 2035-03-04 --credential-description DescriptionHere
If you want to preserve the App Secret, which is what I needed, I already had created the secret and started using it, make sure to pass the existing password.
az ad sp credential reset --name {name of your AD app} --password {whatever password you want to keep} --end-date 2035-03-04 --credential-description AppAccess
--credential-description is optional but if you don't pass one it will be blank on the UI which is not nice.
Further info:
https://learn.microsoft.com/en-us/cli/azure/ad/app/credential?view=azure-cli-latest
There is an Azure Active Directory feedback request to allow for extension of expirations without having to reset the passwords. Please upvote it as it would be a nice way to solve the issue of having to go through all apps using a Client Secret every few years.
Azure DevOps allows for this on your Personal Access Tokens (PAT). Would love for this to work the same way and allow for extensions in both the CLI as well as the portal:
https://feedback.azure.com/d365community/idea/c9d2da85-8be2-ec11-a81b-6045bd7ac9f9
It can't be changed unfortunately, not even by manipulating your App registration manifest directly (that's how you change most things that are not supported with their UI).
Great, now you have to set a reminder for yourself to update that application in time. If you leave the company there is a good chance the people after you will forget it and break your application from one day to the next..
Very unusual, that client secret supposedly is only known to your server - how exactly does forcing you to change it after 2 years (in which is was evidently unbroken) ANY safer? Now your Azure-operators have to tell your devs/devops the NEW client-secret.. that is a high-senitive information that has to be transferred SOMEHOW - completely unnecessary risk!
That reminds me a bit of companies where you need to change your PW every month. I think at this point in time it is well understood that this actually lowers your security, because people are lazy and find all kinds of workarounds, like appending numbers (worst case: the current month) to the password, greatly weakening the password strength overall.
Same if you have to send a new client-secret for one of your clients every year. Sure everyone KNOWs that you are supposed to use a safe channel (as far as that even exists), but this just invites security issues born out of lazyness, stress or simply human error
Well done Microsoft, i feel safer already..
Client secret lifetime is limited to two years (24 months) or less. You can't specify a custom lifetime longer than 24 months.
Microsoft recommends that you set an expiration value of less than 12 months
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-a-client-secret
I am doing SAML SSO in my project , the scenario is I am preparing SAML Auth Request URL ,there is a login page where 2 radio buttons are there for Internal/External User ,In both radio case I have to prepare SAML Auth with the IDP Urls provided to me , I was able to prepare and it redirected me to Microsoft login page ,I been given credentials in that domain to login ,the issue is one person sitting in US tries to login with the credentials was successfully able to login ,got the SAML Response and it redirected him to Redirect URL ,when I took the same credentials of him ,tries to login from my machine ,I got error like you are not authorized ,I been confused what does happen ,we are using the same credentials but machine is different ,Is there any settings in Azure Active Directory which checks NETWORK/Machine/IP as well ?
Yes, they do sign-in risk detection based on many factors.
Location is one of them.
The one you probably hit is this one: https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-risk-events#impossible-travel-to-atypical-locations.
It is impossible for this user to have traveled that large of a distance in such a short time,
so it gets flagged as suspicious and blocked.
I've had this happen as well when I signed in to an account through a VM in another continent.
It does learn typical locations over time though, so it might start working later.
The algorithm ignores obvious "false positives" contributing to the impossible travel conditions, such as VPNs and locations regularly used by other users in the organization. The system has an initial learning period of 14 days during which it learns a new user’s sign-in behavior.
You should have your own user id :)
Edit
It is not a duplicate: The other question is about Sign Up, this is about Sign In. What's more: That question is about email verification, this question about quotas/throttling. Those are different elements of a middleware policy. Although the consequences could be similar, the issue itself and also the solution is different. Please remove the duplicate flag
In case of a malicious user scripts her/his Sign In/Sign Out against your application/web site, which uses AD B2C it can cause millions of Sign In within a reasonable short term.
Because of you will be billed based on the count of Sign Ins (free for < 50 000, then pay) this will not be a happy hour.
Question
Is there any way to prevent the scenario above? (limiting payment is not an option, this case after the attack your site will be unable to serve Sign In user flow)
Azure AD B2C has mitigation techniques against malicious attacks like you the ones you described, and B2C will automatically lock out the user for a certain period of time.
More info: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-threat-management#password-attacks
At the moment, with smart lockouts(as mentioned in the link above) admins cannot control the number of attempts. But if you want to be able to configure that and maybe, even take an action (like MFA) you can do that with custom policies: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-get-started-custom
Azure AD B2C community on GitHub has a sample to lock out the user after 6 unsuccessful sign-ins.
https://github.com/azure-ad-b2c/samples/tree/master/policies/lockout
Any help is really appreciated for the following scenario:
How Amazon.com is managing different level of authentication, once at when you visit the site and second when you go to "Your Account"-> "Login & Security" as a security feature?
User logs in (i.e. authenticates) to a website and there is no activity for 7 days. The user revisits the website then user is asked to authenticate again. This can be implemented using cookies but due to security issue, it was implemented using the session token from the server side. After 7 days, when the expired token is provided by the browser, user is challenged to re-authenticate again.
Now, the new requirement is that if the user logs in and visits "Your Account" page then,
if the user still on "Your Account" page and there is no activity for 10 minutes, then user should be challenged to re-authenticate again.
OR.
if the user comes out of the "Your Account" page and revisits the "Your Account" page after 10 minutes, then user should be challenged to re-authenticate again.
So with the token, I can manage only one time period of inactivity, how can I handle multiple states, i.e. state (7 days) and partial state (10 minutes).
What is the industry practice to handle this scenario? Don't want to use cookies as security issue. And as an SSO provider is being used for authentication, use of database will be the last option.
-- David.
How you could handle this is going to boil down to the implementation details of your current expiring session token logic.
A common way to do it is to store your session tokens in a database or in-memory cache. If that's the case, you could simply add a new column that indicates when the user opened the accounts page.
As an example, your new column could be called accountSettingsStartTime. Normally it would have no value, but when the user navigates to the accounts page, it would be populated with the current time. When the user navigates away from the accounts page, you could clear it out. Then, when you check a security token, you just need to check your standard 7 day expiry as well as checking the accountSettingsStartTime column and ensuring it's within the last 10 minutes.
Alternatively, you could give the user a whole new session token with an expiry of 10 minutes when they navigate to account settings, and enforce the usage of that token for operations that involve account settings. You could then check that token when account settings are changed and ask the user to re-authenticate if it has expired (and invalidate their standard 7 day token). Of course, this would require more effort on the client side.
As they say, there's more than one way to skin a cat :)
When using local accounts, can we force a password change every N days?
If not, can we use the graph api to determine the last time the password was changed?
You're not going to like my answer but...
At this time, Azure AD B2C does not support forced password reset. I would vote for it here.
At this time, the graph API also doesn't support when a password was last changed. Vote for that here.
The Azure AD B2C Team updated the user voice request here.
So now you can use an extension policy to force the password expiration, you can take a look at the code here.
Also, the Azure AD Team released a similar feature, updating the user voice request here.
The property is called:
lastPasswordChangeDateTime
and indeed seems to be the correct one:
The time when this Azure AD user last changed their password. The date
and time information uses ISO 8601 format and is always in UTC time.
For example, midnight UTC on Jan 1, 2014 would look like this:
'2014-01-01T00:00:00Z'
See the updated official documentation for the Graph API.