We have an app which uses the OAuth auth Code grant type. We are trying to restrict session tokens and limiting to 10 minutes however after applying the policy it is not working and users stayed logged in on browsers.
Can you please suggest If we missing something, we are using the below policy :
$policy = New-AzureADPolicy -Definition #('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSessionSingleFactor":"00:10:00","MaxAgeSessionMultiFactor":"00:10:00"}}') -DisplayName $policyName -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
Please do not use that, as per the link that Joy posted. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes
Microsoft is deprecating this. and changing to authentication session management capabilities in the aad Conditional access menus.
"After hearing from customers during the preview, we've implemented authentication session management capabilities in Azure AD Conditional Access. You can use this new feature to configure refresh token lifetimes by setting sign in frequency. After May 1, 2020 you will not be able to use Configurable Token Lifetime policy to configure session and refresh tokens. You can still configure access token lifetimes after the deprecation."
Here is the link: https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime
This feature is in preview - Configurable token lifetimes in Azure Active Directory (Preview), also the New-AzureADPolicy command just belongs to the AzureADPreview module.
Currently, it just works with the parameter -IsOrganizationDefault $true, the feature may have not been implemented completely.
$policy = New-AzureADPolicy -Definition #('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSessionSingleFactor":"00:10:00","MaxAgeSessionMultiFactor":"00:10:00"}}') -DisplayName $policyName -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
Update:
Sorry for my oversight, the solution above is what I test in this post on 2020/4/17, but there is an update in this doc as #alphaz18 mentioned:
So if you want to configure the session lifetime, you need to use the new feature - Configure authentication session management with Conditional Access.
Related
I am working with PowerShell. So we can connect MFA enabled O365 through connect-exopssession but we need to manully enter password and Code sent to mobile. But I want to schedule a solution which has to connect to O365 automtically without any manual intervention in MFA enabled O365. Is there any solution which can bypass MFA without disabling MFA in O365.
The only way to do this is to setup an account that is dedicated for these types of tasks and remove MFA for it, or use Conditional Access to bypass MFA when connecting from your Public IP etc. Just make sure that you secure this account as much as possible.
To create non-interactive scripts, you need EXO V2 PowerShell module version 2.0.3 preview or later version. This unattended script authentication uses Azure AD applications, certificates, and Modern authentication.
Connect to Exchange Online PowerShell with existing service principal and client-secret:
To connect Exchange online with existing service principal and client-secret, you need to follow the steps below.
Step1: Get an OAuth access token using Active Directory Authentication Library (ADAL) PowerShell.
Step 2: Create PSCredential object
$AppCredential= New-Object System.Management.Automation.PSCredential(<UPN>,<Token>)
Step 3: Pass the PSCredential to the EXO V2 module.
Connect-ExchangeOnline -Credential $AppCredential
For more information please read https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#setup-app-only-authentication
Use App passwords. App passwords do not need MFA.
From docs:
An app password is a code that gives an app or device permission to access your Office 365 account. If your admin has turned on multi-factor authentication for your organization, and you're using apps that connect to your Office 365 account, you'll need to generate an app password, so the app can connect to Office 365.
Read more and how to in MS Docs here:
I can get Power BI token via Power shell by using this command Get-PowerBIAccessToken
Token is valid but expiration time of this token is 1 hour.
I want to extend this token to 1 day but I can't find information how I can do that.
I logged into PowerShell from master account.
I tried to create New-AzureADPolicy token with new value of expiration time, but now I cant to assign this policy to the current user(master account). As I understand this policy can be assigned only for a Service principle and I'm not a service principle
Do you have any solution to extend token's lifetime?
If you are running a secure unattended service, your best approach would be to use app-only authentication (a.k.a. "service to service") to obtain an an access token to the Power BI service. Your app's access to Power BI will not be dependent on any user's account, it will have it's own service identity.
You can read more about Power BI support for app-only access to the Power BI API: https://learn.microsoft.com/en-us/power-bi/developer/embed-service-principal
With app-only flows, you have two options to authenticate the app:
With a certificate - this is the more secure, recommended approach
With a client secret - this is less secure, and carries a higher security risk
The Power BI cmdlets support both modes of app-only authentication. For example, to authenticate using a certificate, it's a simple as:
Connect-PowerBIServiceAccount -ServicePrincipal `
-Tenant "{tenant-id-or-domain}" `
-ApplicationId "{client-app-id}" `
-CertificateThumbprint "{cert-thumbprint}"
Alternatively, using a client secret:
$clientSecret = Get-SecretFromSomewhereSafe # Do NOT include the secret in your script!
$cred = [PSCredential]::new("{client-appid}", $clientSecret)
Connect-PowerBIServiceAccount -ServicePrincipal `
-Tenant "{tenant-id-or-domain}" `
-Credential $cred
Once you've connected with either approach, then you simply get an access token immediately before you would use it:
Get-PowerBIAccessToken
If the existing cached access token is still valid, it will be returned. If it has expired, the cmdlet will take care of retrieving a new one.
I have custom extension attributes in an Azure Active Directory (mapped via Azure AD Connect). The extension attributes on Azure AD take the form extension_<uniqueid>_<attributename>.
I want to expose several extension attributes to an application when the user logs in via Open ID Connect. The attributes should be included in the JWT token.
I tried using the approach from the Microsoft Page creating a policy and assigning it to the Service Principal ID of the application that wants to receive the token at login.
These are the powershell commands I used.
Connect-AzureAD -Confirm
New-AzureADPolicy -Definition #('{"ClaimsMappingPolicy":{"Version":1,"IncludeBasicClaimSet":"true","ClaimsSchema":[{"Source":"user","ID":"extension_uniqueidretracted_extensionAttribute13","SamlClaimType":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/extensionAttribute13","JwtClaimType":"MyCustomClaim1"},{"Source":"user","ID":"extension_uniqueidretracted_extensionAttribute14","SamlClaimType":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/extensionAttribute14","JwtClaimType":"MyCustomClaim2"}]}}') -DisplayName "ExtensionAttributeMapping" -Type "ClaimsMappingPolicy"
Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of the Policy>
Creating and assigning the policy works, but the attributes are still not included in the token.
What do I need to do to make this work?
Make sure that you set the acceptMappedClaims to true in the application's manifest in Azure AD.
Try using "ExtensionID":"extension_uniqueidretracted_extensionAttribute13" instead of "ID":"extension_uniqueidretracted_extensionAttribute13" in the ClaimsMappingPolicy.
You;d need to use the optional claims feature to get the information in the extension attributes available in the access tokens.
Please go through the doc Configuring directory extension optional claims, which explains how this is achieved.
I want to connect to Exchange Online using PowerShell and modern authentication without depending on any modules or dll's.
There's a module available for modern authentication to Exchange Online that depends on the CreateEXOPSSession.ps1 and Microsoft.Exchange.Management.ExoPowerShellModule.dll, I have decompiled the latter and found that it generates an access token as such:
TokenInformation accessToken = TokenProviderFactory.Instance.CreateTokenProvider(new TokenProviderContext(authType, "a0c73c16-a7e3-4564-9a95-2bdf47383716", this.AzureADAuthorizationEndpointUri, acquireTokenEndpoint, this.UserPrincipalName, this.Credential, clientAppRedirectUri, (Action<string>) (s => this.WriteWarning(s)))).GetAccessToken();
I want to request the access token is the same way in PowerShell but I can't seem to get the right authentication context and method of retrieving the access token.
Any ideas?
You have to have an MSOL connection and create a remote session to EXO to use EXO cmdlets. There is no workaround for this.
The dependencies are there for a reason. The backend plumbing of MSOL / Azure / O365 expects what it expects, and skirting it will just lead you down a very frustrating/hair-pulling activity.
That token is an Azure AD as MA/ADAL requires that you have an Azure AD Premium license.
MA requires use of the ADAL API/DLL. This is like asking to programmatically connect to and use Exchange on-prem EAS/EWS services without using the API/DLL, that's not a thing either.
So, no matter how you look at this, there will be dependencies, as noted below. So, if you are serious about this effort, you need to really dig into what MA really is and how it's plumbing really works. Also, MFA must be already enabled for you and users, either in O365 and or the ADAL MFA settings in Azure.
Modern Authentication – What is it?
Modern Authentication brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms.
Microsoft identity platform authentication libraries
There is also an ADAL module on the MS PowerShellGallery.com.
Microsoft.ADAL.PowerShell 1.12
ADAL module for PowerShell
https://www.powershellgallery.com/packages/Microsoft.ADAL.PowerShell/1.12
Functions
Get-ADALAccessToken Clear-ADALAccessTokenCache
Examples are here:
Microsoft.ADAL.Powershell ```
####Example 1 This example acquire accesstoken by using RedirectUri from contoso.onmicrosoft.com Azure Active Directory for PowerBI
service. It will only prompt you to sign in for the first time, or
when cache is expired.
Get-ADALAccessToken -AuthorityName contoso.onmicrosoft.com `
-ClientId 8f710b23-d3ea-4dd3-8a0e-c5958a6bc16d `
-ResourceId https://analysis.windows.net/powerbi/api `
-RedirectUri "http://yourredirecturi.local"
See also:
Azure-AD-Authentication-with-PowerShell-and-ADAL
This is a set of really simple PowerShell scripts which allow you to get access tokens with Azure Active Directory using ADAL.
and this...
ADAL and PowerShell
Is there any way I can warn my user when they are configuring their task that this particular task requires use of the SYSTEM_ACCESSTOKEN variable? I have added a check in my task:
if($env:SYSTEM_ENABLEACCESSTOKEN -eq $false){throw "OAuth Token Access not enabled! Set in the Agent Phase Options."}
That is ok, but the user won't find out until they have already kicked off a release which in this cause would fail. I didn't see anything in the extension manifest.
Tasks don't need explicit access to the OAuth token. Tasks are always privileged and can request the access token through the VSTS Task SDK.
To access the REST APIs use:
$vssCredentials = Get-VstsVssCredentials
$collectionUrl = New-Object System.Uri((Get-VstsTaskVariable -Name 'System.TeamFoundationCollectionUri'
-Require))
Add-Type -LiteralPath "$PSScriptRoot\Microsoft.TeamFoundation.Core.WebApi.dll"
$projectHttpClient = New-Object Microsoft.TeamFoundation.Core.WebApi.ProjectHttpClient($collectionUrl,
$vssCredentials)
$projectHttpClient.GetProjects().Result
See also:
https://github.com/Microsoft/vsts-task-lib/blob/master/powershell/Docs/FullHelp/Get-VstsTfsClientCredentials.md
https://github.com/Microsoft/vsts-task-lib/blob/master/powershell/Docs/FullHelp/Get-VstsVssCredentials.md
If needed, you can also extract the token from the returned credential.
The Access to OAuth token checkbox is only required when a custom script needs access to the Build's user token.