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
Related
Short context: I joined a company less than a year ago, the IT department was just one guy before me, with an MSP to pick up the slack. We have one service account for all services at the company (and honestly, whatever. its not ideal and def on the changelist) But part of the issue is that when I joined, I had to do a huge security overhaul, including changing super insecure passwords on everything, including the service account.
I changed the auth info on every service I know that uses the service account, but we're running into an issue now where that account is being locked out, presumably because of repeated failed password attempts. I asked the one guy, all his thoughts are things I already checked. My hunch is that the MSP set something up and just never said anything. Does anyone have any ideas on how I can figure out where this failing login is?
I am trying to release the pipeline from .NET Core application manually. Am able to do that by using a PAT token. But I came to know that the token has a validity of 1 year. So after that my .NET Core application wont work as expected.
Is there any solution in order to solve this issue or is there any other way to accomplish releasing pipeline without using PAT? I tried with the below URL
https://github.com/microsoft/azure-devops-dotnet-samples/blob/main/ClientLibrary/Samples/Release/ReleasesSample.cs
The mentioned cs file uses APIs of Release Management, which support PAT authentication.
Each PAT has a expired date, the default period is 30 days and the maximum period is one year. This is intended to prevent PAT from being leaked to pose a threat to the user’s personal information security in its long-term use.
At the same time, I found a known suggestion ticket in Developer community. You can vote and follow this ticket. You can also create a new suggestion ticket here. The product group will review these tickets regularly, and consider take it as roadmap.
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.
This question is going against the grain of every best practice I've been taught, but it's a larger issue with my current organization. The crux of it is, I need to see what a users password currently is, not just reset it. There are a few reasons for this.
My organization has an active directory, but it is used solely for remote terminal services. There is propriety software in place that does not sync with anything and we manually create user accounts within these various programs/databases, and just manually set their credentials to the same ones they use to login to their office 365 account. The online exchange is the heart of our business, not the active directory.
Due to this, passwords are set to never expire, and a masterlist is kept of all users and their passwords. All of this is transparent to the end user, as far as they are concerned, they only have one account across everything because they're logins are the same for everything, but that is because we manually set their credentials as the same. Now when a user forgets their password (especially our mobile guys as they receive their phones/tablets already logged in and rarely know their passwords) we consult the master list. However, in this circumstance, the user, for whatever reason, is not in the masterlist.
This has probably been the case for months but was only just noticed when I had to set them up with a new tablet. The user does not know their password, and without the masterlist I can't see what it is. The only other option I see available to me is to reset the users exchange password (I'll explain the process I follow below) and have the user call me every time he is unable to login to something, go to it, and reset his password or (in some cases) create him a new account (which is not at all ideal as he will loose all of the linked data he has built up over the years) and start again.
I am well aware how poor these practices are and have been pushing hard to get them changed, but that is another matter.
Now the way I currently reset a users password (as the office365 webapp does not allow manually setting of passwords) is to run powershell off my IT laptop with the exchange, azure admin and azure sign in assistant plugins, and enter the following commands:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -credential $UserCredential -Authentication Basic –AllowRedirection
Login with my domain admin account
import-pssession $session
and
connect-msolservice
This gets me to the online exchange powershell session where I can run the password reset command
Set-MsolUserPassword –UserPrincipalName TYPE_USERNAME_HERE –NewPassword TYPE_DESIRED_PASSWORD_HERE -ForceChangePassword $False
However I need to see what the password currently is. In my searching I have found many resources explaining how to get information about when the password was last set, if it's set to never expire, that sort of thing. However so actual answers on how to retrieve the users current password (and display it in a readable format as, presumably, it will be encrypted). I have, however, been led to believe it is possible by this post I found:
Powershell Scripting example link
So I basically need to know what powershell commands to run to retrieve and decode a users current password. I am my organization I.T. Admin and have full admin rights. Also, this is my first stack exchange post so let me know if there's any additional information you need. I appreciate the help.
Short answer: It's not possible.
Passwords are not directly stored in Active Directory, they are hashed and it's that hash that is stored. When you enter your details, the system hashes the password you entered and compares it with what it has stored. The algorithm used to make that hash is one way only and as such, the only way to get back to a password is to brute force crack it.
Long answer: It might be possible if you change an AD setting which changes how passwords are stored (i.e. reversible encryption) but to do that would be pretty crazy.
We are using Oauth2 with Azure. And by default server returns token with an hour interval for expiration. Is there any way change expiration interval?
It is now possible to configure the token lifetime. You can read more here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes.
Remark: This feature is in preview and will not go to production in this way. The following header is also placed on the documentation link I mentioned above.
After hearing from customers during the preview, we're planning to replace this functionality with a new feature in Azure Active Directory Conditional Access. Once the new feature is complete, this functionality will eventually be deprecated after a notification period. If you use the Configurable Token Lifetime policy, be prepared to switch to the new Conditional Access feature once it's available.
Original answer:
Currently there is no way to change the expiration interval. These are the current expiration times.
Access tokens last 1 hour
Refresh tokens last for 14 days, but
If you use a refresh token within those 14 days, you will receive a new one with a new validity window shifted forward of another 14 days. You can repeat this trick for up to 90 days of total validity, then you’ll have to reauthenticate
Refresh tokens can be invalidated at ANY time, for reasons independent from your app (e.g. user changes password). Hence you should NOT take a dependency on the above in your code – your logic should always assume that the refresh token can fail at any time
Refresh tokens issues for guest MSA accounts last only 12 hours
Source: http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/ and also my own experiences.
You have to use power shell to perform 2 steps as below:
Create new policy. This policy sets timeout 2 hours
New-AzureADPolicy -Definition #('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00","MaxAgeSessionSingleFactor":"02:00:00"}}') -DisplayName "MyWebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
Apply this policy to your website
Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of the Policy>
Note:
In order to get ObjectId of the ServicePrincipal, run this command: Get-AzureADServicePrincipal
To get ObjectId of the Policy, run this command: Get-AzureADPolicy
For more detail you can refer to this document: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
Assuming you're talking about Azure AD, AFAIK it is not possible to do so.
However, in the response along with token you get back a refresh token as well that can be used to get a new token. What you can do is cache the refresh token and expiry time and before making a request you can check if the token has expired (or about to expire). In that case you make use of this refresh token to get a new token and then make your request.