Forefront TMG, Outlook Anywhere, KCD and the “403 : The server denied the specified uniform resource locator” issue.
24 November 14 09:39 PM | forefrontsecurity | with no comments

Dear All,

I have to share that with you, because it makes me crazy during a couple of days.

To give you a quick overview of our organization :

  • 1 resource forest, mono domain, with an Exchange 2010 organization, published (for the /owa URL only) by a Forefront TMG server farm
  • Exchange Mailboxes are linked mailboxes
  • 1 accounts forest, 4 domains (1 root, 3 child domains)
  • 1 bi-directional forest trust relationship

Recently, we decided to published Outlook Anywhere with our TMG infrastructure.

  • Publishing of all the URL Associated to Outlook Anywhere
  • Pre Authentication on the TMG
  • Kerberos Delegation for the authentication on the CAS Servers

We first tested the publication in our staging environment, with success. Then, “copy and paste” the configuration in the production environment. And unfortunately, the tests were KO.

Here is my troubleshooting steps:

  • Open the outlook client, and try to access my mailbox : KO, prompted many and many times for my credentials, and no connection
  • On the EMS server, I started the live logs, and filtered the results with the name of my Outlook Anywhere Rule.
  • Instead of trying to connect with the Outlook Client, which tries a lot of different connection, I have only tried to get an access on the autodiscover URL (that is part of the URL published in my OA Rule). So, with IE, I tried to access https://myexchange.domain.com/Autodiscover/Autodiscover.xml
  • I was prompted for my credentials, but get the “403 : The server denied the specified uniform resource locator (URL)” error. This URL is part of my publishing rule, and if I try to access it from one of my TMG server, it was working properly. So what is really happening ?
  • We had a look on all our network equipment, just to be sure that there is no issue, filtering, firewall rules, but nothing.
  • We had a network trace on the Exchange CAS Servers, but unfortunately, we never saw an HTTP GET /Autodiscover/Autodiscover.xml request. That’s obviously very strange, and points that the issue is located on the TMG side
  • Ok, if it is on TMG, let’s try to simplify a little bit the publishing, and remove the Pre Authentication, and the Delegation (no delegation, but client may authenticate directly) : Test OK !. So it may be related to the Kerberos Delegation
  • So we made a network trace on the domain controllers pf the Resource Forest, and discover that, during the authentication process, we got a Kerberos Error (KRB-ERROR) : KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
  • Damn it, why do I have this error in my production environment, while it was working perfectly on preproduction ?
  • I redo the autodiscover tests, but this time with a resource forest mailbox : Test OK
  • I redo the autodiscover tests, with an account in the root domain of the account Forest : Test OK
  • So, it may be related to the authentication of the accounts in the child domains of the Account Forest.
  • It is time to ask your favorite search engine. Many Times. And after a while, you can find this article : http://technet.microsoft.com/en-us/library/cc752953.aspx
  • At the bottom, there is a little mention, but so important :

It doesn’t matter how deep the domain structure is built; if the KCD and account domains are separated by more than one domain hop across a forest trust, KCD will fail when the user credentials are provided using NBDomain names.

And there is a link to the MSKB 949015, that explain how you can “declare” your childs domain on the Forest Trust Relationship. I applied it, and all started to work as expected !! This KB is a gift, and many thanks to Yuri Diogenes and Jim Harrison for this very helpful technet article !

The so annoying MSIS7000: Signin request not compliant ADFS error
13 January 14 11:03 AM | forefrontsecurity | with no comments

Dear All,

Anybody working with SAML or WS-Federation and ADFS 2.0 may have encountered this tricky error :

MSIS7000: The sign in request is not compliant to the WS-Federation language for web browser clients or the SAML 2.0 protocol WebSSO profile.

In my case, this error occurred randomly, making the troubleshooting more complicated. It happened during the SAMLRequest.

With an HTTP log analysis software (like Fiddler), I captured a bad request, and a good one. This error is related to the format of the request, so I tried to figure out where the difference was. Nothing relevant, except the signature of the request, of course.

I tried to active more ADFS, WIF and WCP logs, following this wiki article. The only error related to the bad request I found was :

MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.

Just to be sure that the error was not related to the signature value, or to other thing related to the diggest, transform method and so on, I configured my RP to allow non signed request. Lucky me, I have a sandbox environment :). Just ran the following cmd :

Set-ADFSRelyingPartyTrust -TargetName "My SandBox RP" -SignedSamlRequestsRequired $false

After all, my Saml request looks like

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://mysandboxrp/samlauth/login"
Destination="https://sts.mydomain.net/adfs/ls/" ID="_78f61282-4688-4e80-ad8d-8753b468fc22"
IssueInstant="2014-01-13T9:38:22Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://mysandboxrp/samlauth</saml2:Issuer>
</saml2p:AuthnRequest>

I used the online SAML debugger to generate my SAMLRequest and got :

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxzYW1sMnA6QXV0aG5SZXF1ZXN0IHhtbG5zOnNhbWwycD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCkFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly9teXNhbmRib3hycC9zYW1sYXV0aC9sb2dpbiIgDQpEZXN0aW5hdGlvbj0iaHR0cHM6Ly9zdHMubXlkb21haW4ubmV0L2FkZnMvbHMvIiBJRD0iXzc4ZjYxMjgyLTQ2ODgtNGU4MC1hZDhkLTg3NTNiNDY4ZmMyMiIgDQpJc3N1ZUluc3RhbnQ9IjIwMTQtMDEtMTNUOTozODoyMloiIFByb3RvY29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdzOkhUVFAtUE9TVCIgVmVyc2lvbj0iMi4wIj4NCjxzYW1sMjpJc3N1ZXIgeG1sbnM6c2FtbDI9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPmh0dHBzOi8vbXlzYW5kYm94cnAvc2FtbGF1dGg8L3NhbWwyOklzc3Vlcj4NCjwvc2FtbDJwOkF1dGhuUmVxdWVzdD4=

I put that in an html form :

<form name="saml_request" method="post" action="https://sts.mydomain.net/adfs/ls/">
   <input type="hidden" name="SAMLRequest" value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxzYW1sMnA6QXV0aG5SZXF1ZXN0IHhtbG5zOnNhbWwycD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCkFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly9teXNhbmRib3hycC9zYW1sYXV0aC9sb2dpbiIgDQpEZXN0aW5hdGlvbj0iaHR0cHM6Ly9zdHMubXlkb21haW4ubmV0L2FkZnMvbHMvIiBJRD0iXzc4ZjYxMjgyLTQ2ODgtNGU4MC1hZDhkLTg3NTNiNDY4ZmMyMiIgDQpJc3N1ZUluc3RhbnQ9IjIwMTQtMDEtMTNUOTozODoyMloiIFByb3RvY29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdzOkhUVFAtUE9TVCIgVmVyc2lvbj0iMi4wIj4NCjxzYW1sMjpJc3N1ZXIgeG1sbnM6c2FtbDI9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPmh0dHBzOi8vbXlzYW5kYm94cnAvc2FtbGF1dGg8L3NhbWwyOklzc3Vlcj4NCjwvc2FtbDJwOkF1dGhuUmVxdWVzdD4=" />
   <input type="submit" value="Submit" />
</form>

That gave me this Submit Button HTML Page (Nice :) ):

image

And when I clicker on the submit button, I got the same error. Great, seems it is not linked to the Signature block !

So, what is different between the 2 requests ? The IssueInstant value. According to the SAML Specifications Assertion Schema, it should have the following format :

<attribute name="IssueInstant" type="dateTime" use="required"/>

This is also what the SamlAssertion Property is waiting, according to the definition of the property. Do not asking me why, but 2014-01-13T9:38:22Z is not compliant with a DateTime format. 2014-01-13T09:38:22Z is.

So I changed the SamlRequest, and Voila ! No error. By the way, now, I realized that the error only appeared in the morning. It was indeed perfectly logical.

As a conclusion, when you are encountering this error, try to simplify the SAML assertion the more you can, to target the bad attribute. In my request, it was pretty easy. But it is not always the case.

Published by Olivier DETILLEUX

Important Changes to the Forefront Product Line
20 December 13 10:53 PM | forefrontsecurity | with no comments

Dear All,

You certainly heard about this news : After the anouncement last year of the end of life of Forefront TMG, now it is the turn to Forefront UAG. 

"Microsoft will not deliver any future full version releases of Forefront UAG and the product will be removed from price lists on July 1, 2014."

So, for any customers that deployed UAG this year because of the announcement regarding TMG, at the end, the result now is the same. It is quite unfair, since Microsoft told in the 2012 announcement, that "It is important to note that there are no significant changes to the Forefront Identity Manager or Forefront Unified Access Gateway roadmaps.  These solutions continue to be actively developed".

Hope that FIM will not end after the major release in 2015 ...

Published by Olivier DETILLEUX

A strange behavior when a Microsoft Certification Authority is deployed in a cross-forest environment, with external trusts
20 December 13 05:03 PM | forefrontsecurity | with no comments

Hi,

Recently, I deployed a Microsoft Certification Authority in a resource forest. You can find a great article on technet about this architecture : http://technet.microsoft.com/en-us/library/ff955845(v=ws.10).aspx

In that article, there is no ambiguity : Chapter 1.2 : Create a two-way forest trust between the resource forest and account forests

Ok, fine, but I do not have forest trust in my environment. Anyway, we deployed.

After some tests with Windows 7 computers, we didn’t see any limitations of this “unsupported” architecture. We started to encountered issues with Windows XP computers : manual enrollment and autoenrollment failed. Each failed request was linked to a permissions issue (for instance, Access Denied (EventID 13, AutoEnrollment Source). In a Wireshark trace, we can see that an anonymous request is sent to the CA)

So we decided to test this enrollment in a lab environment, first with an external trust, then with a forest trust. You can find the result below :

Trust Relationship Type

Windows OS

Type of request

Result

Comment

External

Windows 7

MMC Enrollment

OK

 

External

Windows 7

Auto Enrollment

OK

 

External

Windows XP

MMC Enrollment

KO

Error related to permissions issues. In the Wireshark trace, we can see that an anonymous request is sent to the CA

External

Windows XP

Auto Enrollment

KO

Access Denied (EventID 13, Source AutoEnrollment). In the Wireshark trace, we can see that an anonymous request is sent to the CA

Forest

Windows 7

MMC Enrollment

OK

 

Forest

Windows 7

Auto Enrollment

OK

 

Forest

Windows XP

MMC Enrollment

OK

 

Forest

Windows XP

Auto Enrollment

OK

 

So at the end, Forest Trust is mandatory since you still have Windows XP computers in your domain.

Published by Olivier DETILLEUX

ADFS, a SaaS Relying Party, and the Windows Time Service
20 December 13 02:01 PM | forefrontsecurity | with no comments

Dear All,

Recently, I deployed an Oracle Cloud App as a RP of my ADFS Service. Nothing tricky, the federation was easily put in place, and the first tests were good.

But after a while, some users were experiencing authentication issue. The Oracle error message was :

Access Denied : the assertion has timed out

After a lot of exchanges with the Oracle Support Team, we finally agreed that sometimes, we got a time offset about 300 milliseconds between our servers, causing this error message.

Both environment (Oracle and ours) are time synched with external NTP servers, based on an atomic clock. So, at the end, we may have the same time.

After investigation, I found that my ADFS servers, but also every servers or computers in the domain (or not), are experiencing time drift, sometimes up to 300 or 400 ms. You can check that by using the following cmd :

w32tm /stripchart /computer:yourNTPServer /period:300

That command returns result like :

11:52:17 d:+00.0019276s o:-00.4483183s 

d: shows the delay to receive the packet, and o: is the offset, in ms.

I was looking for a way to fine tune the time service, through the registry keys, without success. At the end, I found this KB :

http://support.microsoft.com/kb/939322

In that KB, you can read :

We do not guarantee and we do not support the accuracy of the W32Time service between nodes on a network. The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs. The W32Time service is primarily designed to do the following:

· Make the Kerberos version 5 authentication protocol work

· Provide loose sync time for client computers

The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds. Such tolerances are outside the design specification of the W32Time service.

At the end of the KB, you can find a link to a list of NTP Client that are more accurate :

http://www.nist.gov/physlab/div847/grp40/softwarelist.cfm

After installing a third-party time service, time drift was limited to max 40 ms.

image

If by any chance, you know a way to have a Windows Time Service more accurate than the default behavior, feel free to propose your configuration in the comments.

Published by Olivier DETILLEUX

An update for ADFS 2.0 is available to fix several issues after you install security update 2843638 on an AD FS server
20 December 13 10:49 AM | forefrontsecurity | with no comments

Hi,

If you missed it, there is an important update for ADFS, published on Nov 13, 2013. This update fixes issues if you have deployed the Security Update 2843638. You can find the update there : http://support.microsoft.com/kb/2896713

For me, it helps in solving the following issues :

MSIS0038: SAML Message has wrong signature

Also, removing the KB2843638 helps in fixing that issue

Published by Olivier Detilleux

Filed under: , ,
The SID Translator tool is available on Codeplex
27 October 13 10:21 PM | forefrontsecurity | with no comments

Dear all,

If you were a reader of the blog, I have posted last year the first release of a custom tool : an Active Directory SID Translator.

Now, the source code is available on Codeplex.

Hope you will find this tool useful.

Filed under: ,
New release of my Custom Ldap Repository Store for ADFS 2.0
27 October 13 10:12 PM | forefrontsecurity | with no comments

Dear All,

Long time I haven't updated the blog. New job, less time to work on personal IT project. No more MVP either.

Anyway, you can find on Codeplex the last release of my LDAP Attribute Store for ADFS 2.0.

Hope you will enjoy this new release.

Published by Olivier Detilleux

ADFS 2.0 Cross Forest and Cross Domain Requirements
28 April 12 03:42 PM | forefrontsecurity | with no comments

Hi,

One of the recurrent question about ADFS 2.0 is how many Federation Server is needed in a cross domain or cross forest scenario.

The Active Directory Identity Provider is able to authenticate through Trust RelationShip. Cool ! But what kind of trust ?

Forest Scope and Trust Relationship Requirements

Based on my own test, here is an answer :

  • In a forest, because all child domains are automatically trusted with bidirectionnal trust, only one federation service is necessary in the forest.
  • When there are other forests, the minimum level of Trust Relationship is Bidirectionnal External Trust, as in the following schema

image

  • External trust are not transitive. You can use Forest Trust and the transitivity to extend the scope of the Active Directory IdP
  • If you have a selective Domain Or Forest Wide Authentication on your Trust Relationship, you have to a)dd the “Allow to authenticate” right to the trusted domain users

image

  • The Name Suffix Routing allow you to restrict the access to the Trusting Forest. Check that the UPN of the remote users does not contain suffix that are disable. In the following example, the user jbono@uag.corp cannot authenticates :

image

  • You can also block specific UPN with an ADFS Deny Rule :

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Value =~ "^.*@gemalto\.corp$"]
=> issue(Type = "
http://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

Access Denied

Published by Olivier DETILLEUX

ADFS 2.0 A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider : Client Certificate Authentication with a “standalone” CA
26 April 12 05:57 PM | forefrontsecurity | with no comments

Hi,

In a previous post, we have seen how we can provide client certificate authentication.

That was pretty simple, because we used an entreprise CA, an adfs server and a user account, all in the same domain.

An other challenge is to use Client Certificate provided by a Standalone Certification Authority (in an other forest or in a workgroup, and of course not integrated in the Active Directory).

The global architecture I wanted to test is the following :

image

Here is how I have achieved this scenario, with the troubleshooting method

First think to do is to request the StandAlone CA (named USER CA in my case) for an User Certificate. I have configured my StandAlone CA to authorize domain users to request user certificates. Automatically, with the User Template, I receive a Client Authentication Certificate.

  • The CDP mentionned in the Certificate Properties must be accessible from the ADFS Server.
  • The Subject must be a valid path in the Active Directory (in my case : (E = james.kirk@labtest.com,CN = James Kirk,OU = Users,OU = Corporation,DC = labiam,DC = corp) OR the subject alternative name must contain a Principal Name that is the UPN of the user (for example : Principal Name=jkirk@uag.labtest.corp). This is the User Mapping that IIS uses to find the user in the Active Directory. If that is not the case, you may encountered a “Logon failure: unknown user name or bad password”

Now, I have a Certificate. If I try to signin on my Federation Service, I receive a “403 - Forbidden: Access is denied.”

image

Not an ADFS error, but an IIS error. We can use the Failed Request Tracing logs to see what is happening. To enable Failed Request Tracing :

  • Check that you have installed the IIS Tracing Module

image

  • In the IIS Management Console, under the Default Web Site, click on the Failed request tracing and Enable

image

  • You can now define your filter. In my case, my filter is concerning the 403 return code

image

If we look in the last Tracing log, we can see the following issue : Access Denied

image

I add the Certification Authority Certificate Chain in the Trusted Root Certification Authorities, and signin again. Now I have the following message :

image

Yes ! an ADFS error. Have a look on the ADFS Server Event Viewer. There are 2 events :

  • Source : AD FS 2.0, Event ID 111, 364

The Federation Service encountered an error while processing the WS-Trust request.
Request type:
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue

Additional Data
Exception details:
Microsoft.IdentityModel.SecurityTokenService.FailedAuthenticationException: MSIS3019: Authentication failed. ---> System.IdentityModel.Tokens.SecurityTokenValidationException: ID4070: The X.509 certificate 'E=james.kirk@labtest.com, CN=James Kirk, OU=Users, OU=Corporation, DC=labiam, DC=corp' chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. 'A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.

My Certificate is detected, but the authentication failed. After a quick search, I find that the thumbprint of the root CA Certificate must be located in the  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ EnterpriseCertificates\NTAuth\Certificates registry key.

The NTAuth Certificate Store are trusted to both issue authentication (logon) certificates for any user in the forest and enable logon for smart cards, Internet Information Services (IIS) mapping, and Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).

Sounds good. First, I have to extract the public key of my Certification Authority. We can do that with the Certificate MMC, and export the certificate without the private key.

Then, use the CertUtil command to add the .cer into the NTAuth Certificate Store :

certutil -enterprise -addstore NTAuth <CertificationAuthorityKey.cer>

And that’s it, authentication is successfull and I can access to my Claims Aware App :

image

To summarize, what we need :

  • A StandAlone Certification Authority that deliver Client Authentication Certificate with an alternative name containing the UPN of the user
  • No needs to import the delivered certificate in User Object in Active Directory
  • Add the Certification Authority Certificate Chain in the Trusted Root Certification Authority of your ADFS Server (and on the client computer)
  • Add the public key of the root CA in the NTAuth Enterprise Store
  • Publish the CRL

Published by Olivier DETILLEUX

Translate and Compare Object SID : Download SIDTranslator
20 April 12 10:10 PM | forefrontsecurity | with no comments

Hi,

When you work with Active Directory, did you never had to translate an objectSID from a string to hexadecimal format or vice versa ? Now, there is a tool to do that : SIDTranslator.

With this tool, you can :

  • Translate a SID from String to Hex or Hex to String (any kind of Hex : 01050000 … , 0x01 0x05 0x00 0x00 … , 01 05 00 00 …)
  • Compare two SID, no matter the format.

image

You can download this tool here : SIDTranslator.zip. The password of the zip file is sidtranslator.

Published by Olivier DETILLEUX

ADFS 2.0 : The first release of my Custom LDAP Attribute Store is on CodePlex
18 April 12 11:23 AM | forefrontsecurity | with no comments

Hi,

As you know, there are three “out of the box” Attribute Store in ADFS 2.0 :

  • Active Directory
  • SQL
  • LDAP

But there is a limitation with the LDAP Attribute Store. As this Technet Article says (http://technet.microsoft.com/en-us/library/ff678034(v=ws.10).aspx) :

When you work with other Lightweight Directory Access Protocol (LDAP)-based attribute stores, you must connect to an LDAP server that supports Windows Integrated authentication. The LDAP connection string must also be written in the format of an LDAP URL, as described in RFC 2255.

This is not the case for all LDAP server. Mostly, you connect with a simple bind, with a ldap user account that has the right to read. For this kind of ldap server, we have to build a custom attribute store. This is the purpose of my CodePlex Project, that I am happy to share with you.

You can find the project here : http://ldapattributestore.codeplex.com/

Feel free to test or to participate if you want. I am not a developer, so any improve in the code will be awesome Sourire

Published by Olivier DETILLEUX

ADFS 2.0 : HomeRealmDiscovery customization for Multiple Local Authentication Methods and Mobile Device Detection
16 April 12 10:29 AM | forefrontsecurity | with no comments

Hi All,

This article is the second part of a series about Multiple Local Authentication Methods with ADFS 2.0. Here is the first part

This article is a brief synthesis of some great article :

Customization of the HomeRealmDiscovery page is a great solution to add custom behavior during passive authentication. For example, adding browser detection, subnet detection, and providing automatic redirect.

Enable the HomeRealmDiscovery

But to enable the HomeRealmDiscovery feature, ADFS must act as a pure relying party STS (RP-STS) (This is when AD FS 2.0 has configured claims providers, but all local authentication methods are disabled in the web.config file. AD FS 2.0 can only direct the user to authenticate with a trusted STS.) or as an Hybrid STS (This is when AD FS 2.0 has configured claims providers, and uses a local authentication method).

If you remember my use case, for the moment, my ADFS is acting as a pure IP-STS. If I want to enable HomeRealmDiscovery and local authentication, I have to transform my IP-STS to an hybrid STS. To do that, I have just created a “fake” claims provider trust.

Now, when I want to sign on my application, I can see this menu where Other is my “fake” claims provider trust :

image

If I select my Active Directory Identity Provider (adfs.labiam.net), I will be redirected to the default Local Authentication Handler (as seen in the first part).

First part of the customization is to rewrite this menu to show the list of Authentication Methods I want to use. The initialization of the list is done in the Page_init function :

protected void Page_Init( object sender, EventArgs e )
{

PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;
PassiveIdentityProvidersDropDownList.DataBind();
}

The base.ClaimsProviders return the list of the enabled IdP in ADFS. We can modify this code to list the local authentication types :

protected void Page_Init( object sender, EventArgs e )
{

PassiveIdentityProvidersDropDownList.Items.Add("Integrated");
PassiveIdentityProvidersDropDownList.Items.Add("Certificate");

}

Now, when we click on the button, we must be redirected to the correct URL (see part 1). We can do that in the PassiveSignInButton_Click function.

protected void PassiveSignInButton_Click(object sender, EventArgs e)
{
    switch (PassiveIdentityProvidersDropDownList.SelectedItem.Value)
    {
        case "Integrated":
            Response.Redirect("
https://" + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/integrated/" + HttpContext.Current.Request.Url.Query);
            break;

        case "Certificate":
           Response.Redirect("
https://" + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/sslclient/" + HttpContext.Current.Request.Url.Query);
            break;

        default:
            break;
    }

}

Now, we have the following list :

image

Remember the last choice

During the redirection, some cookies are created. One of those cookies is the MSISIPSelectionPersistent. This cookie is the persistent cookie which is written to the file system on the client that shows who should be the identity provider (IDP) for this client. In my case, it is a problem, because if I am automatically redirected to my AD IdP, I will be prompted by the default Authentication Method (yes, again, see the part 1). We can disable this persistence in the web.config file : change <persistIdentityProviderInformation enabled="true" lifetimeInDays="90"/> into <persistIdentityProviderInformation enabled="false"/>

Ok, great, but now, the user should always choose an authentication method, each time he close his browser. We can create an other cookie, to keep in mind the selected authentication method.

switch (PassiveIdentityProvidersDropDownList.SelectedItem.Value)
{
    case "Integrated":
        Response.Cookies["MSISPAuthenticationMethod"].Value = "Integrated";
        Response.Cookies["MSISPAuthenticationMethod"].Path = "/adfs/ls";
        Response.Cookies["MSISPAuthenticationMethod"].Domain = HttpContext.Current.Request.Url.Host;
        Response.Cookies["MSISPAuthenticationMethod"].Expires = DateTime.Now.AddDays(8d);
        Response.Redirect("
https://" + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/integrated/" + HttpContext.Current.Request.Url.Query);
        break;

    case "Certificate":
        Response.Cookies["MSISPAuthenticationMethod"].Value = "Certificate";
        Response.Cookies["MSISPAuthenticationMethod"].Path = "/adfs/ls";
        Response.Cookies["MSISPAuthenticationMethod"].Domain = HttpContext.Current.Request.Url.Host;
        Response.Redirect("
https://" + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/sslclient/" + HttpContext.Current.Request.Url.Query);
        break;

    default:
        break;
}


Then we can add the detection of the cookie and automatically redirect the user to the previous authentication handler. In the Page_init, add the following code :

if (Request.Cookies["MSISPAuthenticationMethod"] != null)
{
    switch (Request.Cookies["MSISPAuthenticationMethod"].Value)
    {
        case "Integrated":
            Response.Redirect("
https://" + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/integrated/" + HttpContext.Current.Request.Url.Query);
            break;
        case "Certificate":
            Response.Redirect("
https://" + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/sslclient/" + HttpContext.Current.Request.Url.Query);
            break;
    }
}

Now, during the first logon, a cookie is created :

image

Mobile Device Detection

Now, I want to redirect automatically iPhone, iPad and Windows Phone to the sslclient authentication handler.

During the Page_init, I can add the following code :

if (HttpContext.Current.Request.UserAgent.Contains("iPhone") || HttpContext.Current.Request.UserAgent.Contains("Windows Phone") || HttpContext.Current.Request.UserAgent.Contains("iPad")  )
{
    Response.Redirect("
https://" + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/sslclient/" + HttpContext.Current.Request.Url.Query);
}

Now, when I access my Claims Aware Application through my iPad (I have added 2 user certificates on my iPad to show how it is working) :

The web site requires a certificate

Select a certificate

I choose the certificate of James Kirk, and I am automatically log on.

My web application prints the claims of my token. We can see that the value of the authenticationmethod is tlsclient

image

Published by Olivier DETILLEUX

ADFS 2.0 : How to provide Multiple Local Authentication Methods
15 April 12 10:23 AM | forefrontsecurity | with no comments

Hi,

For one of my customer, I am deploying a federation service to provide transparent authentication on Web Application for employees.

ADFS is acting as a pure identity provider Security Token Service (IP-STS), in other words, there are no claims provider, except Active Directory account store in the domain where the service resides.

Users are authenticated on their domain joined computers, so we can use Integrated Authentication to provide transparent logon. But my customer wants to provide, for a specific population, a transparent logon from a mobile tablet, connected to the internal WiFi network of the company. Integrated authentication is in that case not a solution.

For that specific population (VIP of course), my customer has generated user certificate from the internal Certificate Authority. If we can provide a client certificate authentication when a mobile device requests an authentication, we could provide transparent login.

This article is the first part of a series that explain the entire solution, passing by Local Authentication Methods, HomeRealmDiscovery customization, Cookies …

Local authentication Methods

As you can read in this msdn article : http://msdn.microsoft.com/en-us/library/ee895365.aspx there are 4 local authentication methods when you request an authentication to ADFS 2.0 web site :

  • Integrated
  • Forms
  • TlsClient
  • Basic

By default, those 4 authentication handlers are activated. To specify what authentication methods you want to use, you have to change the order of the handler in the web.config file. For example, to force forms authentication, reorder the <localAuthenticationTypes> list to put the following line at the first place : <add name="Forms" page="FormsSignIn.aspx" />

When a web application is requesting a SAML token through passive federation, the application redirects the user to the ADFS sign in web site. The ADFS web site then validates the request and then, based on the AD FS 2.0 configuration and the request parameters, AD FS 2.0 invokes authentication handlers in the order in which they are specified in the web.config file in the Sign-In Pages.

From the application side, you can add a query string (with the wauth parameter) to the sign in request, to ask for a specific authentication methods :

User name and password authentication

urn:oasis:names:tc:SAML:1.0:am:password

SSL client authentication

urn:ietf:rfc:2246

Windows integrated authentication

urn:federation:authentication:windows

But if no authentication parameter is added to the sign in request, the first authentication handler is chosen.

After the authentication method detection, user is redirected to the relevant sign-in url.

User name and password authentication

https://adfs.labiam.net/adfs/ls/auth/basic/?<queryString>

SSL client authentication

https://adfs.labiam.net/adfs/ls/auth/sslclient/?<queryString>

Windows integrated authentication

https://adfs.labiam.net/adfs/ls/auth/integrated/?<queryString>

Forms https://adfs.labiam.net/adfs/ls/FormsSignIn.aspx/?<queryString>

In my case, we cannot modify the application, so we cannot add the relevant wauth string. The idea is to make an url rewriting just before the authentication request.

In the next article, we will see how we can do that during the passive federation request by customizing the HomeRealmDiscovery page.

Next step : HomeRealmDiscovery Customization

Published by Olivier DETILLEUX

Lync Server Control Panel : Insufficient access rights to perform the operation – A strange Active Directory PropertySet issue
11 April 12 05:33 PM | forefrontsecurity | with no comments

Hi All,

Today, a colleague of me asked me to help on a strange Lync Server issue.

The symptoms was :

  • From the Lync Server Control Panel, he was unable to view the Lync Enabled Users
  • He was unable to “lync enable” user
  • The error message was “Insufficient access rights to perform the operation”

There are many articles and forum where you can find some help :

  • Check the membership of the lync server computer account : OK
  • Check the inherited permissions : OK
  • Check that the target user is not member of an builtin admin group : OK
  • Check ACLs in details : OK, using this technet article : http://technet.microsoft.com/en-us/library/gg398742.aspx

All Acls seems to be good. But this kind of issue is always a rights issue, so I decided to go deeper in those ACL.

First, to be sure that this is a right issue, I have enable Directory Access Failure Logon, and for a specific user, I have enable Fail Audit for all attributes and properties issued by the Lync Server Computer Account. You can do that in the Security Tab of an user account :

image

Then, I tried to “lync enable” the specific user account, and I found in the security logs of my Domain Controller, the following Failure Audit :

image

As you can see, it seems that my Lync Server doesn’t have the right to write 3 properties :

  • msRTCSIP-PrimaryUserAddress
  • msRTCSIP-UserEnabled
  • msRTCSIP-PrimaryHomeServer

That was strange, because in my mind, I think that the Lync Schema/Forest/Domain preparation should create a delegation on those properties for the RTCUniversal-UserAdmins group.

In that technet article http://blogs.technet.com/b/jenstr/archive/2011/02/07/grant-cssetuppermission-and-grant-csoupermission.aspx I have found that the RTCPropertySet and the RTCUserSearchPropertySet should contain those attribute.

Had a look in the configuration partition, and found the 2 PropertySet in the Extended-Rights container :

image

Then I found that the 3 Lync Properties was not in a property set. So, I change 2 attributes on each schema attribute :

  • attributesecurityGUID : rightsguid of the PropertySet
  • isMeberOfPartialAttributeSet : true

image

image

After a schema refresh (right click on schema partition and Refresh Schema Now), the Lync Server Control Panel was working well.

Published by Olivier DETILLEUX

More Posts Next page »

This Blog

News

    We talk about Forefront Unified Access Gateway, Web SSO, DirectAccess, Threat Management Gateway, Identity Manager and other Forefront Technologies. Also, some post about Active Directory and other Identity and Access technos.

Syndication