I can submit requests to authenticate and the response is just fine.  I have ADFS configured to send me a persistent name ID using instructions from here: http://blogs.msdn.com/b/card/archive/2010/02/17/name-identifiers-in-saml-assertions.aspx

I know that the Requester status code means there is something wrong with my request message, but I can't figure out what is wrong.  I've got tracing turned on as described here:http://blogs.msdn.com/b/card/archive/2010/01/21/diagnostics-in-ad-fs-2-0.aspx

But I don't see anything in either the debug logs or in the regular logs that points me to the part of the message that is incorrect.  I've validated my request against the XSDs provided by OASIS.

Can anyone help?  Are there some settings somewhere I should turn on to provide even more debugging information?  Or is there something obviously wrong with my SAML request?

An example of a request message:

<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_df18d04d7325bef3ecb3" Version="2.0" IssueInstant="2012-10-05T22:03:46.888Z" Destination="https://dc1.org.testna.me/adfs/ls/"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">TestSamlApp</saml:Issuer><saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">+543LSsx5Bs/NqZuwtdoBediy78qfXi3owHKJbtc+sQ=</saml:NameID></samlp:LogoutRequest>

Signed and converted to redirect format:

https://dc1.org.testna.me/adfs/ls/?SAMLRequest=nZFPa8JAEMW%2FStirmM0fU8NgAoqU2lqhVUrxUtbsxgaS3bgzQfvtu0YP0oOHHmfm%2Fd68YSYomrqFpdmbjt7VoVNI3qmpNUI%2FyVhnNRiBFYIWjUKgAtbT1yVEfgCtNWQKU7Mb5D4hEJWlymjmLeYZ%2B5JlmMpgJMdxlOxUGatiFzPvQ1l0mow5xAkRO7XQSEKTawVhNAyDYZBsogiCGEYPfpqmW%2BbNXfZKC%2BrJb6IWgXNZhL6xe5%2FcUAu%2FUVzIEnmNnOWTc17o7e0%2FLsg3znPtgGnbTviN19V45djF3Hs0thF03%2FTcqeSw7KXQns9HUppYPkhG8XKNp2SGfHXYdkeSZqZk9TNOD%2BVnFZvj08vzjooBvmXXEJe9%2BaX689v8Fw%3D%3D&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=nnJeG2zW1dVqprfVKUihwKDvD44tNstRgWKeClUQXwQ5uWfmZ8K27w9k2fHC%2BUaGOM5k8obJYR3pRfY8GWd5tq7uRQRp0wjUpNJWD7JrlAv0qJRgmetfD9KTDCRJTl7vVm7keVS7V43JqpP4iEQfdy%2FR%2BEB2ADE%2FtKVCAAvbu%2FcV00r47ZJsmOXDEoINh9EhXpE7t%2BTNFaHrVwYN2srzckFhUXfGvpG6wwAhxA4oBT8VPY%2FWiN2eWgFoYUsDzYEfvjU9TNxMFRK2FaHO6KA1jgr%2FI8LTZ0%2B%2Bz91PhWJn5iWr%2FxpJObZCuxYXaxtcmSDWAYk%2BAX7lP77Ti37LuC%2BH9g%3D%3D

The response I'm getting from ADFS:

<samlp:LogoutResponse ID="_570da7da-8d7e-4e1f-b417-4b80cee1a426" Version="2.0" IssueInstant="2012-10-05T23:03:39.952Z" Destination="https://localhost:3000/saml/logout/callback" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_df18d04d7325bef3ecb3" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://dc1.org.testna.me/adfs/services/trust</Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><ds:Reference URI="#_570da7da-8d7e-4e1f-b417-4b80cee1a426"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><ds:DigestValue>r/6mxT5Lu71BohKUlyNfnmiYLt8=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>JRprCiBCZVEWJbFh4dmiqrq0DrlrLmlWQ5gfDay/dfxrkZxKZjkm4Cyrl7THrSmC4ASoBlxD6jb+e1WA6rcSr0PUH7u9H1KQ1vB/3APxUBlOaBsndg6SgD5PBP1fHqI1n9fDgIH6XdmMBs6NADkXMbeNjF1Ti5UDLZo5kncs8TJLFLnbGOtIXQaDpDeTqP0nmvCyV0VQ1nnjnClhIkl2kaGddf7lfOdRmHtAiEMxG8uuBlxsBFdZ2uUnSDXyjxxpB8WsDazcRdius2UQ+WaXFYcHCn8CkXeFJKlkQbWSkDubQtKA8NkpqKZyMRNq3bRXYeGJHT9x89NUX+hpK4Vt6w==</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC5jCCAc6gAwIBAgIQRjJu6D+dUKREnbGOWi77xjANBgkqhkiG9w0BAQUFADAcMRowGAYDVQQDExFkYzEub3JnLnRlc3RuYS5tZTAeFw0xMjEwMDEyMzExMTRaFw0xMzEwMDEwMDAwMDBaMBwxGjAYBgNVBAMTEWRjMS5vcmcudGVzdG5hLm1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzCjyneYPzRzybJ/K6NCRDQ7NsbitYr5UxVOMGjYGybm9cc+zLSFAVSaZBRHfQFKI59lfDnHk99v1vskXz+wMx8h/UFgYW/lR2NYWDsQgYM/IVzRmgFgXIRAc32tIhRH8f+XAKl+Rig/FGOnGXNPl77r35m24hunuq+CG3BqydLQhDeSc8W0pUaCx5QeJCxd0mVC46zy0OsqCkx1E1DrbHHDclHsYaf0hcRQxFeQg7RQHQVgznNgJxtXEvNpCsTkoX0Xtn2jJx6LUW9rz1mdTT6SWtPIKhvyOmkp2BiL0sznL5dxuaG8jN8LhICbIL0RHfZY6xJ8G+ecfkkxroSgKuwIDAQABoyQwIjALBgNVHQ8EBAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQEFBQADggEBABjTkuVWmGN6chD+4Y/jfr56QIcMDW+dsdJvNUtUXaG46B4SZ+fNeR1RPAM9QHp11OlpL1t/i1tPVn6jpy4QkPTqmQhYGPydt+Z2up+wJneX8+waKf6nrGgSJaMMcwQ6250x5Q3+jfyqX/ekw+uHOwnbXQWtVWVbLSOGnHdRW2hgNbY0btCN/0DYX5KODzYxQu6JmZefgNjW69wEi42ZnO5gN7Elkdaeyks5zX43fSH/QpQfrrWMDaZqsFCUkBe/bhYljZvE5FYioUwUkaXXtESjmTmm30GvOx/cBdXz040CDssk7bIe6LeYRSv1I3sEaO5kPbfqvzD3rXpIw1wJds8=</ds:X509Certificate></ds:X509Data></KeyInfo></ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester" /></samlp:Status></samlp:LogoutResponse>

Assuming mixed mode security (i.e. layer 7 blobs sent over layer 4 ssl), which is the better service-side implementation strategy: do NOT declare a service cert, or declare one and expose a DNS/cert identity claim for the endpoint?

if you look at ACS' own mex metadata, there are *no* identity claims attached to the endpoint addresses/references. If you think about it, why would blobOverTransport (mixedmode) even required a layer 7 "messaging-centric" service cert?

I one does impose it, it seems to give problems, re id validation DURING server=side processing. The issues are "not intuitive"

My *impression* is that IF you assign a behavior with a service cert to a mixed security endpoint, various messaging-level controls are imposed then - when preparing the output response (post GetScope). And these can induce some of WCF/WIFs horrid panoply of miserable error messages, including things discussing dns claims (that seem to be induced by incompability between service cert CN fields and endpoint identity DNS value declarations). As usual in WIF/WCF world, the error messages are worse than the error (being totally misleading).

So, if ALL I WANT IS username blob over https, accompanying an RST, should I have the STS NOT declare a service cert for the service/endpoint.

(this seems to be what thinktecture does, for (only) mixed mode).

Hi,

I am trying to download the Windows Identify Foundation Runtime from url:

http://www.microsoft.com/en-us/download/details.aspx?id=17331

then selecting:

Windows6.1-KB974405-x86.msu

but the download fails.  I checked with our network people and we don't seem to have a problem.

Is there another way to download the runtime?

Thanks

Naveen H

I'm having a problem with inserting claimoffered for an existing claim provider within powershell.  The command I'm trying is:

PS C:\> set-ADFSClaimsProviderTrust -TargetName 'SomeFed' -ClaimOffered 'http://identity.schemas.somesite.com/2008-05-15/#Id'

Error I receive

Set-ADFSClaimsProviderTrust : Cannot bind parameter 'ClaimOffered'. Cannot convert the "http://identity.schemas.somesite.com/2008-05-15/#Id" value of type "System.String" to type "Microsoft.IdentityServer.PowerShell.Resources.ClaimDescription".
At line:1 char:67
+ set-ADFSClaimsProviderTrust -TargetName 'SomeFed' -ClaimOffered <<<<  'http://identity.schemas.somesite.com/2008-05-15/#Id'
    + CategoryInfo          : InvalidArgument: (:) [Set-ADFSClaimsProviderTrust], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.IdentityServer.PowerShell.Commands.SetClaimsProviderTrustCommand

I found a post where some said to just re-import the MetaData however the problem I have is the Metadata supplied contains no claims and other pieces that I have had to fumble through using powershell to configure, and re-importing will get me nowhere.

I want to use. NET to build a server, the client has winform, asp.net, ios, Android. This situation can use Windows Identity Foundation certification?

Thanks!

相信自己，坚持下去。

Hi,

I have situation where I have a set of application in the perimeter network.

I have an internal AD in corporate network for our internal users.

I have to maintain a separate AD in perimeter network for external users /customer who need access to the perimeter applications.

How many ADFS instances I need?

Can I configure ADFS instance in corporate network and a ADFS proxy in perimeter network.

Is it possible to add internal AD and perimeter AD in the internal ADFS instance to serve both internal and external user to access the perimeter applications. without a trust between internal AD & perimeter AD.

Or I need to setup 2 different ADFS instances one for perimeter and one for internal? and in this case how to configure the application redirect to multiple ADFS instances to get STS for internal users from internal ADFS and for external users from perimeter ADFS?

Also, what should be the proxy server placement?

Thanks,

Soumen Ghosh

I am trying out ADFS 2.0 as Identity Provider for SAML2.0

I have created a self signed certificate using IIS Manager. I then used it to Create a new Federation Service.

While setting up in the Add Relying party Wizard: after selecting the "Enter data about the relying party manually" --> "ADFS 2.0 profile" --> "Configure certificate" --> browse. I am not able to find the certificate that I created from IIS Manager.

Though I find the certificate in the certificate manager console. I am unable to figure out the physical path to my certificate.

Please help.

Thanks in advance.

Does anyone know if it's possible to customize the logos on the Claims Provider selection Screen?
i.e. if you have multiple Claims Provider trusts, I would like to give each of them a meaningfull logo instead of the Default Icon.I have seen that I can Change them in General (and this is possible going to work for my current Scenario), but I cannot customize them on a per-Provider base.

Thanks
Michel

Hi!

I installed the February 2011 Identitiy Developer Training Kit. One of the prerequisites is the WIF 4.0 SDK.

I wanted to download the German version, but it is only the 3.5 version available. So I took the english version.

But when I try to install it, I get an msi error:

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738.

The MSI-logfile shows this:

MSI (s) (08:70) [19:46:07:049]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIEA07.tmp, Entrypoint: DetectWindowsIdentityFoundation

MSI (s) (08:78) [19:46:07:049]: Generating random cookie.

MSI (s) (08:78) [19:46:07:051]: Created Custom Action Server with PID 4760 (0x1298).

MSI (s) (08:E4) [19:46:07:077]: Running as a service.

MSI (s) (08:E4) [19:46:07:078]: Hello, I'm your 32bit Impersonated custom action server.

MSI (s) (08!80) [19:46:07:094]: PROPERTY CHANGE: Adding WIFRUNTIMEINSTALLED property. Its value is '6.1.7600.0'.

MSI (s) (08!80) [19:46:07:094]: PROPERTY CHANGE: Adding WIFINSTALLFOLDER property. Its value is 'C:\Program Files\Reference Assemblies\Microsoft\Windows Identity Foundation\v3.5\'.

MSI (s) (08!80) [19:46:07:094]: PROPERTY CHANGE: Adding WIFREFERENCEASSEMBLIESDIR property. Its value is 'C:\Program Files\Reference Assemblies\Microsoft\Windows Identity Foundation\v3.5\'.

MSI (s) (08:70) [19:46:07:094]: Closing MSIHANDLE (4) of type 790542 for thread 5760

Action ended 19:46:07: WifHelper_DetectWindowsIdentityFoundation. Return value 1.

MSI (s) (08:80) [19:46:07:095]: Doing action: SetVS100IdfxTemplateFolder

MSI (s) (08:80) [19:46:07:095]: Note: 1: 2205 2:  3: ActionText 

Action 19:46:07: SetVS100IdfxTemplateFolder. 

Action start 19:46:07: SetVS100IdfxTemplateFolder.

MSI (s) (08:80) [19:46:07:096]: Note: 1: 2235 2:  3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = 'SetVS100IdfxTemplateFolder' 

MSI (s) (08:80) [19:46:07:097]: Creating MSIHANDLE (5) of type 790542 for thread 5760

MSI (s) (08:0C) [19:46:07:097]: Creating MSIHANDLE (6) of type 0 for thread 6668

MSI (s) (08:0C) [19:46:07:097]: Note: 1: 2205 2:  3: Error 

MSI (s) (08:0C) [19:46:07:097]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2738 

DEBUG: Error 2738:  Could not access VBScript runtime for custom action 

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738. The arguments are: , , 

MSI (s) (08:0C) [19:46:08:552]: Note: 1: 2205 2:  3: Error 

MSI (s) (08:0C) [19:46:08:552]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 

MSI (s) (08:0C) [19:46:08:552]: Product: Windows Identity Foundation SDK 4.0 -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738. The arguments are: , , 

MSI (s) (08:0C) [19:46:08:553]: Closing MSIHANDLE (6) of type 0 for thread 6668

MSI (s) (08:0C) [19:46:08:553]: Closing MSIHANDLE (5) of type 790542 for thread 5760

Action ended 19:46:08: SetVS100IdfxTemplateFolder. Return value 3.

Action ended 19:46:08: INSTALL. Return value 3.

Property(S): Manufacturer = Microsoft Corporation

Property(S): ProductCode = {0BD0F49E-C5B3-4FE0-A792-DCD61AEE93CF}

Property(S): ProductLanguage = 1033

Property(S): ProductName = Windows Identity Foundation SDK 4.0

Property(S): ProductVersion = 6.1.7600.16436

Property(S): UpgradeCode = {734C8165-0287-4D52-9FB6-7D68C0AA9124}

So whats wrong? Please help!

Thanks

We have multiple relying party trusts and I have noticed that when a user goes to the logout endpoint it tells them "they are logged out, but for improved security to close their browser."  I then notice they are not logged out, because they can reconnect without authentication, unless they close their browser.  I noticed this issue with multiple relying partners. I am guessing they are not even logged out until the session timeout kicks in?  Also, I thought I had seen a way to adjust the session timeouts through the ADFS 2.0 gui.  I know it can be done through powershell and not worried about it, but if you guys know how I can change it through the adfs 2.0 msc, let me know because I know I have seen it before.  So my guess is that the logout endpoint does not actually remove the cookie with the authentication token in it, but if someone can even tell me how that works, I would appreciate it. 

https://fs.contoso.com/adfs/ls/?wa=wsignout1.0

Dan Heim

Hey there.  I have just configured my first ever application that is using our external ADFS server.  In order to to get it to work, I had to disabled the IWA function in the web.config file as shown below.  

Before disabling IWA, if you tried accessing our federation.domain.com from an internet IP address, you would be directed to our proxy ADFS server in our DMZ.  This DMZ proxy would forward your request onto our internal ADFS server using the windows credentials from the internet computer.  Since the user would not have been on a domain joined computer, his credentials would not work on our internal ADFS server, and the user would see a "401 unauthorized access" error.  As soon as I disabled IWA, the internet user would get prompted for their AD credentials, enter them, and then gain access to the ADFS protected resource. 

There are 2 questions here:

1. Is this normal for IWA on a proxy ADFS to break non-domain access into your federation?

2. If it is not normal, how would a ADFS proxy with IWA enabled ever work?

I know there are some federation trust specific settings for each trust in your ADFS environment (such as choosing to decrypt tokens or not for example).  I was wondering if there is a way to restrict access to the trust to only internal LAN users. So people accessing the trust through our internal ADFS server would get to the trust, but those trying to access the trust through our proxy server would not be able to.  In other words: internet uses would not be able to access the trust, but LAN users would be able to.

Maybe through IP subnet white listing or some similar mechanism?

Thanks for the information.

I have a custom STS that takes around 30 seconds to perform the wsignin1.0 step, which is entirely too long.  I cannot find any evidence that my custom code takes any more than 1 second, so I do not understand what is taking so long.  How long should I expect this part of the login process to take with WIF, and what are some things I can look at to determine why this takes so long in our environment?  Thank you.

Edit:  I turned on a profiler and found something new.  The STS is actually very fast, taking less than a second to process the wsignin.  The part that takes up all of the time is the redirect back to the RP.  This is taking close to 30 seconds, but why?  The RP website should not take anywhere near that long to load.  What is the STS passing back to the RP that could be taking so long?  Once the RP renders, everything is lightning quick, until I log out and have to log back in.

I have several RP's that share an STS for a single sign on scenario.  I have these sites set up in multiple environments.  In one of these environments, each time that I access an RP for the first time, I can see in the browser address bar that the user is being redirected to the STS and then automatically back to the RP.  However, in a different environment, I only get directed to the STS for the first RP that I access, but each subsequent RP that I go to, I can access directly without being re-directed to the STS, first.  Other than that, they both appear to be working the same.

I have tried several different environments, and I believe I see a pattern.  When each RP address is hosted on the same machine, the STS is only used for the first RP, but if the address for each RP is different, then the STS is used for every RP.  So, when all of my RP's are http://mymachine:port, where each RP has a different port number, but same machine name, WIF does not bother going to the STS after the first one, but if I use a different machine for each RP, then the STS is hit each time.  Does this sound right?

Everything runs much faster when I do not have to go to the STS between every RP, but if the browser does not go to the STS, then I do not get the chance to track the RP's in the cookie to enable single sign out.  What is causing this difference in behavior?  I swear the code and configuration is exactly the same between the two environments.  I really need to be able to track the active RP's so that I can use single sign out.

After a patch run last week, whenever an external user attempts to login to a particular RP using SP-initiated HTTP-POST through our ADFS Proxy, the "submit" button 302-redirects them to "/auth/ls/?" rather than to that SP's endpoint. 

KB2843638 causes this behavior on 2008R2, and KB2843639 causes it on Server 2012 (which I built fresh yesterday to examine this behavior).

On both servers I made sure to follow the KB's instructions regarding the FormsSignIn.aspx modifications, though I can't imagine that would cause this.

No other SP's are affected, but they're all using HTTP-Redirect.  Using HTTP-Redirect for this particular SP is not an option due to the tendency for content links to be embedded in emails, which runs afoul of Outlook's wonderful "follow all 302 redirects with a crippled version of IE until you hit a 200 OK, then pass it to the system's browser" behavior.

I have used Fiddler to examine the behavior, which is where I confirmed the incorrect redirect URL.

IdpInitiatedSignOn.aspx works as expected.  After signing in as above (and getting the pointless redirect) I can open a new tab and connect to the RP without getting a subsequent login prompt.  It appears that the last step ("redirect the user to the SP's endpoint") is now broken.

Hi!

I am about to connect two different AD FS2.0 with each other, but so far without success.

I added the "other AD FS2.0" with its FederationMetadata to the "Claims Provider Trusts". On the "other AD FS2.0" I added "our AD FS2.0" by its FederationMetadata as a Relying Party. On the "Claims Provider Trusts" I added a claim rule to transfer those claims.

I configured some claims such as the UPN & samAccountName and on one of our Relying Parties of "our AD FS2.0" I added some delegation Authorization Rules.

When I browse now to the relying party, I can choose now my own adfs2.0 and the other adfs2.0 on the home realm detection page, and I choose and login on the other adfs2.0 which redirects me back to my own one.

But there I always get the exception:

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.

There is no Proxy in between the both AD FS2.0. 

Any Idea what could be the problem?

Thanks a lot,
Dominik

I'm setting/adding claim rules to ADFS using PowerShell, using the following commands:

Add-PSSnapin Microsoft.Adfs.PowerShell
Set-ADFSRelyingPartyTrust –TargetName "MyApplication" -IssuanceTranformRulesFile "C:\Temp\Claims.txt"

The file claims.txt contains the following rules:

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass Through - Name"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(claim = c);

@RuleTemplate = "MapClaims"
@RuleName = "Transform - WinGroup"
c:[Type == "http://schemas.xmlsoap.org/claims/Group", Value == "TestGroup"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
    Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = "TestRole", ValueType = "string");

Both rules work fine, but when looking in ADFS, the second one has no name and is a custom rule, as shown in the dialog below:

This is very annoying for our administrators, because they can't see what the rule does from this dialog. They have to look at the rule itself. It would be nice if the name would be there at least, and preferably the destination claim type as well, as is the case when we manually enter them by clicking Add Rule... You would think PowerShell would pickup the name and destination claim type, because the @RuleName and @RuleTemplate parameters are set.

Thanks for any insight into why this is happening (and what we can do about it).

Hello!

Once again about claims:

This new token (created in 10) does contain the same claim created in 8, doesn't it?

Thank you in advance,

Michael Firsov