Hi All

I’ve just rolled out ADFS 3.0 within my company and everything is working great but now I would like to enable Client certificate authentication and this is where the fun has started.

My environment is the following:

Windows 2012 r2 Domain controller with domain/forest functional level at windows 2012 r2

One domain controller installed as a certificate authority and currently giving out client certificate which is used for client authentication through TMG

ADFS server running windows 2012 r2 which is joined to our domain

ADFS server in the DMZ which is the ADFS proxy server and it in a “WORKGROUP”

Firewall ports which have been opened are HTTP, HTTPS and tcp/49443

When I enable cert auth and try to signin on the following URL (https://sts.my domain.com/adfs/ls/IdpInitiatedSignon.aspx) I get the following error:

An error occurred

Authentication attempt failed. Select a different sign in option or close the web browser and sign in again. Contact your administrator for more information.

Sign in with other options

Error details

• Activity ID: 00000000-0000-0000-1601-0080000000f2
• Error time: Wed, 10 Dec 2014 13:03:26 GMT
• Cookie: enabled
• User agent string: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36

I’ve tried running this internally (Using chrome as my browser to ensure I get prompted for my users cert) to avoid firewall issues with the above result.

When I have a look at the event viewer on the ADFS server the following is logged:

Level: Error

Source:  AD FS

Event ID: 364

Task Category: None

Gerneral:

Encountered error during federation passive request.

Additional Data

Protocol Name:

Saml

Relying Party:

http://sts.<my domain>.com/adfs/services/trust

Exception details:

Microsoft.IdentityServer.AuthenticationFailedException: There is a problem with the X509Certificate provided by the client. The error code is: -2146885613

  at Microsoft.IdentityServer.Web.Authentication.TlsClientAuthenticationHandler.ProcessIntranetRequest(ProtocolContext context, WrappedHttpListenerRequest request)

  at Microsoft.IdentityServer.Web.Authentication.AuthenticationOptionsHandler.Process(ProtocolContext context)

  at Microsoft.IdentityServer.Web.PassiveProtocolTlsClientListener.OnGetContext(WrappedHttpListenerContext context)

I’m now at a loss as what else I should try to get this working. Can anyone advise how I should proceed or how I should be troubleshooting this problem?

Many thanks in advance

Hello

I have a problem when trying to publish Exchange 2010 OWA via Web Application Proxy using Non claims.

The setup:
DC01 - Windows Server 2012 R2 DC with ADFS installed.
WAP01 - Windows Server 2012 R2 with WAP installed and domain joined.
EX01 - Exchange 2010 SP3 CAS

I have installed using instructions for Pre authenticated Non claims application.
1 Non claims application rule in ADFS with Permit all users.
I have edited WAP01 in ADSIEdit and added http/wap01 and http/wap01.domain.local
I have added Delegation on WAP01 to http/ex01 and http/ex01.domain.local
I have changed CAS to Integrated authentication and run iisreset /noforce

The WAP server can resolve DNS names to local servers without problems.

My publish rule for eg. OWA is like this.
External URL: https://mail.domain.se/owa/
Internal URL: https://mail.domain.se/owa/
Cert: *.domain.se

SPN: http/ex01.domain.local

I have a test client on the external side with edited hosts file to point fs.domain.se, mail.domain.se to the firewall and then to th WAP server.

I browse to https://mail.domain.se/owa/ and is presented with the WAP login screen.
When I type my credentials I get a Server error 500.

When testing internally to https://fs.domain.se/adfs/ls/idpinitiatedsignon I can logon without problems.

The WAP log show these 2 event id when I try to logon externally

Event ID: 12027
Web Application Proxy encountered an unexpected error while processing the request.
Error: The user name or password is incorrect.
 (0x8007052e).

Details:
Transaction ID: {0c2a649b-024a-0000-ae67-2a0c4a02d001}
Session ID: {0c2a649b-024a-0000-ad67-2a0c4a02d001}
Published Application Name: Exchange OWA
Published Application ID: E19A1041-46D8-D047-BE18-DA3BEE9967AD
Published Application External URL: https://mail.domain.se/owa/
Published Backend URL: https://mail.domain.se/owa/
User: firstname.lastname@domain.se
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL: https://mail.domain.se/owa/?authToken=<Long token>
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: OuOfOrderFEHeadersWriting
Response Code to Client: 500
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>


Event ID: 13019
Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: The user name or password is incorrect.
 (0x8007052e).

Details:
Transaction ID: {0c2a649b-024a-0000-ae67-2a0c4a02d001}
Session ID: {0c2a649b-024a-0000-ad67-2a0c4a02d001}
Published Application Name: Exchange OWA
Published Application ID: E19A1041-46D8-D047-BE18-DA3BEE9967AD
Published Application External URL: https://mail.domain.se/owa/
Published Backend URL: https://mail.domain.se/owa/
User: firstname.lastname@domain.se
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL: https://mail.domain.se/owa/?authToken=<Long token>
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: BackendRequestProcessing_Pending
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>

Tried using domain\firstname.lastname and it gives the same error. Also tried logging on with both firstname.lastname@domain.se and firstname.lastname@domain.local and changing the UPN accordingly.
I cannot see an issue with certificates either but that can also be because I'm not sure where to look.
I'm beginning to get angry here cause I'm running out things to check. The time is identical so it's not a kerberos time issue.

I've read that some has made this work but I'm beginning to think that maybe it is not meant to work.

Hi,

Fiddler is always showing a 404 for /favicon.ico when passing ADFS (2012 R2).
As we have an 'AdditionalFileResource' option when using an AdfsWebTheme I though it would make sense to just serve up an .ico file, like so:

(Note: linebreaks added for readability)

Set-AdfsWebTheme -TargetName MyCustomTheme 
-AdditionalFileResource @{uri='/adfs/portal/ico/favicon.ico';
path='D:\Program Files\AdfsWebTheme\MyCustomTheme\ico\favicon.ico'}

Unfortunately, this doesn't work. Presumably because all web content is served up from "/adfs/portal/" URL's (and not root).

Would anybody know of an alternative way?

Danny Alvares, Senior Technology Consultant

Hey all,

My organisation have been using Office 365 and AD FS (as we don't sync passwords) for roughly a year now, and we're reaching the point where the self-signed certs in AD FS for token-signing and token-decrypting are going to automatically renew.

The documentation from Microsoft (and popups in our Office 365 tenant) indicate that we need to run the Update-MsolFederatedDomain command for our federated domains or auth will fail once the certs actually expire. We have a lab environment and thought we'd actually let the certs expire to observe the behaviour, and what we found was that without running in the commandlets, the tenant seemed to pick up the newly-generated certificates and auth continued to work.

This leads me to believe that Office 365 must be reading our federation metadata and saw the certificates re-generate and then switch. If that's the case, do we actually need to run those commandlets at all? If Office 365 is monitoring our federation metadata and taking action when something in that metadata changes (you'd have thought 'by design'), then the documentation is either outdated or incorrect?

Curious what others thoughts are on this.

As-is, WIF's Saml2SecurityTokenHandler can write Saml2Assertion that looks like the following:

<saml:EncryptedAssertion>
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

What I want to do is to render an EncryptedKey element that has the @Recipient attribute set:

<saml:EncryptedAssertion><xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/><dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><xenc:EncryptedKey Recipient="recipient1@foobar.com" xmlns="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

Is it supported by WIF out of the box? Can anyone please show me the right direction to do it? Thank you in advance :)

Hi

We want to build an App and expose it via our own internal ADFS servers (we will be the resource partner organisation) to external users

some will be users in "account" partner organisations that have their own AD/ADFS infrastructure - so I understand how the claim/token signing is done etc

but how to we give access in a scenario where a user (say a one man band or consultant) does not have access to an AD/ADFS infrastructure

how is there claim/token generated?

many thanks

I have a fully operational ADFS server running under a WID database. For backup centralization easiness, I’d like to move databases on a SQL Database.

I Followed the steps describes in this article, but when service try to start, the following errors are trapped in theADFS 2.0 admin log :

Log

Name:      AD FS 2.0AdminSource:        AD FS 2.0
EventID:      102
Description: There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Additional Data Exception details: System.ServiceModel.FaultException`1[Microsoft.IdentityServer.Protocols.PolicyStore.OperationFault] :ADMIN0012 : OperationFault (le détail de l’erreur est égal à Microsoft.IdentityServer.Protocols.PolicyStore.OperationFault).

Then :

LogName:      AD FS 2.0/Admin
Source:        AD FS 2.0
EventID:      220
TaskCategory: NoneLevel:  
ErrorKeywords:      AD FS
Description:The Federation Service configuration could not be loaded correctly from the AD FS configuration database.Additional Data Error:  ADMIN0012 :OperationFault

 Enabling ADFS debug logs show these events:

LogName:      AD FS 2.0 Tracing/Debug
Source:        AD FS 2.0 Tracing
EventID:      37
TaskCategory: None
Level:         Error
Keywords:      ADFSPolicyServerService
Description:An erroroccurred while trying to search in the policy store:
Message: Une exception a été levée par la cible d'unappel.

LogName:      AD FS 2.0 Tracing/Debug
Source:        AD FS 2.0 Tracing
Event ID:      53
Task Category: None
Level:         Warning
Keywords:      ADFSSTS
Description: Got exception:ADMIN0012 : OperationFault with stacktrace:   à
Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.Sql.SqlStore.Search(Filterfilter, Int32 maxObjects, String[] propertyNames)   àMicrosoft.IdentityServer.Service.Policy.PolicyServer.Service.SqlPolicyStoreService.<>c__DisplayClass4.<SearchCore>b__3()  àMicrosoft.IdentityServer.Service.Policy.PolicyServer.Service.SqlPolicyStoreService.AttemptDeadlockSusceptibleOperation(DeadlockSusceptibleOperationoperation)  à Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.SqlPolicyStoreService.SearchCore(IPolicyStoreServicestore, Filter filter, Int32 maxObjects, String[] propertyNames)   à Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.SqlPolicyStoreService.SearchDirect(Filterfilter, Int32 maxObjects, String[] propertyNames)   à Microsoft.IdentityServer.Service.Configuration.SqlServiceConfigurationReader.LoadData()   à Microsoft.IdentityServer.Service.Configuration.AdministrationServiceState.FetchAdministrationServiceStateData()   à Microsoft.IdentityServer.Service.SecurityTokenService.STSService.FetchAdministrationServiceConfiguration()while fetching configuration. Will retry in 2000 ms.

These 2 events are repeated 9 times, then this error is raised:

Log
Name:      AD FS 2.0 Tracing/Debug
Source:        AD FS 2.0 Tracing
Event ID:      67
Task Category: None
Level:         Error Keywords:      ADFSProtocol
Description: CreateFromCurrentConfiguration: Unable to read Winhttp configuration. Using direct connection.
 Exception: System.NullReferenceException: La référence d'objet n'est pasdéfinie à une instance d'un objet.   àMicrosoft.IdentityServer.WinhttpProxyConfigurationReader.Read(Uri& httpProxy, Uri& httpsProxy, Boolean& byPassLocalAddresses,
List`1& byPassList)   à Microsoft.IdentityServer.ADFSWebProxy.CreateFromCurrentConfiguration(IProxyConfigurationReaderreader) 

• Opening internet acces did not solved the problem.
• As suggested here, I tried to update Trust Providers registry settings for Account \S-1-5-20, but no success. (I tried value 23c00,200 and 23e00)
• FrameWork.net 4 was deployed on the server, I removed it assuggested here, but no success.
• If I revert configuration to use again the WID database (Data Source=\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query;Initial Catalog=AdfsConfiguration;Integrated Security=True), then the service starts fine.

How can I make this ADFS Configuration works? The funny thing is that having Artficat DB on SQL server and using WID database works very well. Issues came from when moving ADFSCOnfiguration database to SQL.

Thanks in advance.

Romain K

OUch

Hello:

I want to configure Datazen to use Claim Base Authentication,It support ADFS. But i had built a STS by WindowsIdentityFoundation.

The Datazen cannot work with STS.So I try to compare those two Tokens from ADFS and STS.

here is ADFS Token

<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"><t:Lifetime><wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2015-12-03T06:51:58.886Z</wsu:Created><wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2015-12-03T07:51:58.886Z</wsu:Expires></t:Lifetime><wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"><wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>http://datazen2.hnopmoss.com/adfs/services/trust</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><t:RequestedSecurityToken><xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#"><e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /></e:EncryptionMethod><KeyInfo><o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><X509Data><X509IssuerSerial><X509IssuerName>CN=Datazen Enterprise Server API</X509IssuerName><X509SerialNumber>1104860035425614937888597827857490957</X509SerialNumber></X509IssuerSerial></X509Data></o:SecurityTokenReference></KeyInfo><e:CipherData><e:CipherValue>LUvPXvx1ogPJDtm4gKVnGJfRrV+LgtnuXuwLvssgHiotNKMCIM5YAA0TPAK5ASss3+FaQrN3O1rk7+Qm7hag2mAVXYP4igEThBVz+MpZUerB81mUo38Y0ZsAjma5vlvs9GDuOrdTvwrVmWip6MydJ4gSxYR2rfBzQJz1H8w/AjA=</e:CipherValue></e:CipherData></e:EncryptedKey></KeyInfo><xenc:CipherData><xenc:CipherValue>0TqVT3g8YNGsVO4qwVjYnP1i/FJjqKs1+CV9SfafJd6fx4PEDH1197pZHTO0CyIwKzfztwlZpvvCGI1vBFIa43t5njY4ZK1CKa5//BGCtyMgdnmxBU9afbTOZekqy+Dk5iI6EiTbphXBYY3HrfhLzggl6GDszwoFA9RjbPNyd9Ed8U2o5EjzTvfAcUsdfshhW1rfw6a2SKmx+9kChpQHCeO5XQti+3pR2163JjwCkGTY5F43epdyVVu7eLuG13CAnjnvN3DdDDFJxCUHO39MmpzOshHpBOS2eQQOUOs3hx13ePRWsRlTDSRwB2iyIbIi5P7UdJCNbAI56hlWDhzb1o2U370Vift9N9grSNB6vJmDk8Fu7MZuS8IYSmSrWq3SSP9IifsvJo7BZskj9YOEW/qfL+xarpTB7+4oEwf7zy67nrDPmB/qDFneaqH8GZ+DHfQnwtHV9tTpUuD9mlzWv6ScIbRJRK7SJaYXQUy/MmokKAy356kaeZSDFl0rkwWgYBIaY/UzDIwIUZt3q4zxsBo/PHguscn4WYOZrRovdYJNDJZGwFU5yDfUVDYx3Sp8niu1SQrAjGGha1chhnO9zUKEAyt4aLUNZGgtQ2g0bmOTJVAT02gFYjRvhp26D0DDk2WrgyOw5l3arYz2i72+pZAmJaE6Gk66AH3HgCK4ITGKNUoq0EAJUqS0jaFM+xcE+0choGmx7oUh76erBFQpEYmwQ6xAc6ZcJtYHlGvwDCVi/otCvbEjR7yonk2y0PHES6WLgxsnqN9umYACWqzCkyTseJitfJzxgSI5mDLPEPjkac5MCD9jS10mcaO1PBFP+ukQMFaus03X+Uel+z6pi68pUgX3NMBVmXbhsK3976xuwba1LwaLptS0llRrP1DdtX/nbkZ0zwmLw+0oVPcBL7druJ/6SxD69x7kV0QdrZdL2fjrUXlkj5NNsevaUOBe1p6HTt7BaMunj3589pmWSMREkbYjkPSeVRgCMwjnti0Gh1F6V+6yhVcnqxel0XNVZSZIabh1Twnez/oJDx3BcL1m7w+PMRyUIVfL6xGD2Yu3466R92UfmMkQuUM34y9q8qXmGn5Oj9ohjop1ohUzDHtm5oU2/3XicCcdsuKyqog3Z/nAbA/P4OwLvwacfEoiyJ0xf6w9M85/db8XoYKZp77Y336deTLf6xpv4rMm/lxXfxPT+z1Z4RwqKRKOnMNG8M1ZDYRewXmBmuF2WuAKEhUeAvSjJSdlti4xCy8ca0N0xJ2+GPWEEVPWColE0SnE4rdzX/gCtHv7kUb2b+fJcJGpyeIPu6w3GoAcYBux5Y7cwL4wfObXud8UbggjbUh9bKig9Ek/LavXkWYAWwrunlbBmen88o1FrnbOjOU+twlOwDiT9bWru8CbQ0qKhgd4qfWGIDtnbpwDLmCY5g/iSBX0KncySh5eCB1Ql9R89vlEgqvHv6gqLgCUXmPJGkpgQzBDy0Qp5YQm5b9tMgsSbgLbGeeLSr4bEsxyw4dOJb2srQKOxp+GBoQxYI+criiolXA4WVfw52WI7YyxtG448mUKuOAIv7vGZOiESKlSm8xVwC7bR8Vr+mX3o9+R93iUOWqHN7La1ETqrUDuSLTE/3bMg6QXjhPTj43TKP+6ckENw7ZrcLLHjg9qCjwOyl1EwBzBGMmQlajWeyMrdUignGnrFmhx1Ys3fXedSFhrUVwBpZ+xew6JgFdDIvam3XiFgafzWMCZosQMiKaG4zxcplO3x/QAEJQaPt+53TyfzSTV5wVuXK8pZC0/2Sc8oJAWmaYeOui0qHVSgJlWJF0CbzTP86VviF2+DOH2yvUj1GRiqIWYJsunFdIPQKzZ+S5MYbr/Y9VxCbPxVYscqZToeHVzSzFbrnzXO65720ps8NODGLHqIwt3ey2XO5V96zPPizztSES2k05TlwRZ5uX7RPYAfVVGTHbDYllpMphGQNh8/GruwRdAQWQ5MLZ1FdWy8POcSP/9x8z5537/0KLIL1CWiK24WaJINkjj+8XUTTM/n3r3cKE2LtdG8VS56HoYLKQzpQSnO707pH5s5LUazZnF71gNX0WxKxTOKdoAkF75hWPe7M+k+qMIj8Zc6ltp5+4LfNweUW6BWRBgtmGlPlxQAFM36PUppWYV9xESFcxQyWiz3NeR5ygZGuEhCbJkpb1oxY0q3u0t14H+piRDA8VH5i+hAqzQm96Gkrf+z0WDEAW65AsV2Qv/2LTjmGOIGfb++/As1pUeAc/JLMC916x89KQz0rsAY6cXAonsrsNyl7xRw6EGsxIxDs48o4XiWCJJCX54QtxKi0E6SW1Os/9fIfpGbzAJuRQDOAAkdN0LJenAWvZEhz73SZRraQkVtvdYHNWdvhGVwNpjJV/ltO1vQ+KsbJqN7g3SdZpL2wPbavse9EEE5sMTzxFYbGH8Q139OOVMMltQV0AjJz/3xr6JZZ7u8CmcSJzT3tDwDr02u+aJYs9QILOYvXgy3gvrkZ+LpwOEIXZlH/zRt+3g3ywQfDwxjmmookNKA7hfmtk2H7UE2688RcV2lhqTVBhysFZeqgoBXcx4vUiIHn+up80xsCBs/V6CUfg+fuME1ZwqIRG6pzTyROi0SKSU3gLuBk8h1aMcXaEWm6TUI0+mJNJsg9kYnz98DI2wf5BXsuSyr2KHwlU2LpNH9asrcf9ALPIi/a/IegxWi3bMkS5bd84Mr6xqVSp0qNSvSl7sFqJOJ6utuwOs7voRNfLtvJzUUi5yXDuTzhhpkHpiLt0EbibgNVYEp//Nc5+zv2vI0O1BxYIBC4RI1CBf5ZD5jco1uZNbangZ1kbVzhaL6pcljd7ohffsetnDUbnmtwYXhnldeBACG6CK/UQbIJ1mc/COX2B5oqESLIkCYL5r/xq7HfcZrDAzdbFQCSlmmYdXgS60Xza3OSGmAsUig7ESDGJ6sglwbmV0YZXKbD9GNtWqli07NJozrJQCVZf5HVCcImyLMYlN+UHvrmeR1c8DJnG392RV5phX2Tuyz8Md5b2goeMsMLbHX3tHTc2cdlldBLdOHlYzJSQhPGWAUcAuPHlUk10TVE3ieL3ieVSMje88OeH4fA+pIEIuxOKBRljN7pATtsJ5HYEsdYS+Xd8JrOFL77kbh6qRYq0pWp487zk7Rg18W5ke2MH1f8K8SdUsXDMldGmkA7Lz4TiPv+G47IJ9JEDpx8yW9GhN17enFPNWIJtliZfReDXx/RusBmN6o8EOgiYHR5ToNcSmtCGrmLCdIrnjo61yXAEZLda1aD20GdQTig6wdEgR4+Zet/G6AVHEjKwpBRrWBdpO5wUxJkO/Uxw3neP7+K75pHSZY7ocTYmYjflvgtwJ4kHdWyGVH09rUZHLdz+44WrREAmLH8Ci3kcZO/EibUbYCxF/N3SfplUqI9LsZgfIqLU0Leg2Gk0q4SOGjAg6fqPB5CUnEf10P9qeCqfLW7XMD8f+9U9f+tnbXjhcSfCLdmuPcAZQc43KYTe1yZ5nQMfhxC850lYAcGAvZSz1B5rtTVDUhU6mgVPJa/JNm/UX2EWI7P3Hj4/TQ72FUwhyE6Dy12n3NdFJedCSwRJ66qU27ypSpgVQAnlrjZeAaZNKD6jFEHVTpb5w3I0HawbSky+o4maXgtkGXBFPBt3LMaF/G6KYF+MmqKbjh34rTwk1KrIVCLn5qbQYI8+IGVqb7AF/JH17fuEVtR8PJkVbl8556tXP17rMslXtB6uac9OIx6fcZCRbREa48vXgQkgrQTlweFGHld+dDK10XXHPMkm+dp0zEdbSqt8w+NFU9lO3yaJf892JQk+qHdJhFCG/iWwCjkecjMAJrTUOvYqmM7/A5oBloOg8PcmttnuzLzvE9p6UgTXq3TmYqwjxPbm0DAmkHjfUaOHqVic4gbmOlEqHJUj6fkDmbReLPendyJ5sl1TDxmWc7Wjfj8OJD+MlpfSG1sVcx28tIuTYDoLK3oguDLX3rIi10DmHGy5A4fVgad0KRBBGdVQZLdrhs8b5V0ESOQ3jkorC1XHcsVVtIvmcnPst8eikbro3joEPK1oP8BO1aGo4vqkTtX6vZoQco8Pga/JH6yR+S84MN/4tjNzM50Lrmw2OhCeMfHYxqXNyy3QqEwErauK22th9aj+3/BoO0mpl+tztb333vWy3sicG26YPslahFGRBCmKOtna6k+HV997CujIjMYb2xh1CwP9rYVuz96XzXiQge4gWnBNfqm9bzIHulGtH3T2qtR9j/3zer6TzwRkPKT2N9Tc3DWtHEwqBHLEwp/t5odXIVtAQZSsd/VEAQaTPLD2NaCDC90rUIPPTxQ9Y+Przs2ln8GfBmRykrCVBBSBLBRhpLlaqPNI30cbMAQm9gq54S+dWp5HYeANGtpX2b7rR0s5hWMh2RKqpB8OB6TfkhiWG9KtCZGegSqmYg3EchVZb2TZd2jyEh+WFrm2aThOkE6kJk277v5ajbolwbl/ur3g7xiIxAiqfm0+YqShftnsbvXvkbSbeYkcBpI2/gl3lmLIN9GEG5b/M7s4mCfd/AAMRu05J8FUT+TqdzJV0QG4Tno/pe6niM5/hOBNLa6BTnbhI2a2clarmm/JYwOZi8AOFMvN8YrcC/0sKVpSFUjzCwv50N9FD2xaLmuMqQ/l6V//5za5ObbQ9ThCA21teT9en52LyMEsMuKHiI6MxEzOQrj26HRn1FMwg0ELXglb6i/jQLFXG9jVFgY5Cyt9Dw7RghEv8uOHjGkazjUy8MBovbiOeB9IRBYIiTPX+pGhrEJdStHdmpA1vN9vSb0N179eHncgj8GF3uNrYYQd24qD9rbeMMPWoTxzfUwIibuUpRmr3Ox05x1eINW6uI8+ypsfJHxIqu4z5k5ARcCaJtsPY9gtBvwz8v1UKRx4l3SOE9eBkj9/7+FK3IW7qF3VHq5cIpVZ/gmBo8YeNwuHqCVwbGl0eRnn9zuZplcU6R5ARANvnXoxaZDf2ksJnAi7WAl/o0klXjDOqcRN4ole1eogE/4ceTTG7FEE4PWWgI0C1Pmb9KE/QpVtDDvIOMhjxg41OiKB8K0ecj4miIcgODR2gNa5bUYoiFMLL7uVqLXTqv8qS1607EvOY3o9zA2Fy77zegK7v3NTtDbNIQn9RPw957Jr0RFeaITW3baH91d6PCB8NZJ/9C7rFJkHlceSur3oQN4NiMPEW10qI75o+DCO/mWwZ2ZvTMgjMY7AYDsWv+4YQTMmLU8PP4/3vCnoCO9akWtMjkL9mYUXrScOjtavRIkNgK2GubNkLlBpCen3oAdrY4uFAaHi5TUlet/b/FCYmusl7fRhIO2oBVYSYb57FCPoEmyNfV+cBx+Zm/2K0WLvVaZ0F3qpGyGiczigOAZjQmE3Vb7bLmXx4HnzBDUuXWtn0tGBWhDtYbyDS30Xo885XchoPJrLqgYJkCc9s+d85FfNzbH9jEz8Z1Yim8X7Uxk0gMiAq5UVT5Au4rY7fCyWSO4Jwh7xHKC4BG2mu8513PfOfS6qe9nKtScSiSVc41W+5JCun+khIF+Zdfl2gAtqHDHiagpbxVHS2k6AYfuk1XeSnqQf0Hblw9pkvYdPGe3TpujnjOYeb/LHOYQ3UUGXrBDxItTcMeBJYFKUzG2MissiK4xK2FV0Euo/YfdJMzOrsII5K3+eBIIICfqkG8BVbdTxEB3DmaiFI</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></t:RequestedSecurityToken><t:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</t:TokenType><t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType><t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</t:KeyType></t:RequestSecurityTokenResponse>

Here is STS

<trust:RequestSecurityTokenResponseCollection xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><trust:RequestSecurityTokenResponse><trust:Lifetime><wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2015-12-03T08:27:52.937Z</wsu:Created><wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2015-12-03T12:27:52.937Z</wsu:Expires></trust:Lifetime><wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"><wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>http://datazen2.hnopmoss.com/adfs/services/trust</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><trust:RequestedSecurityToken><xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#"><e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /></e:EncryptionMethod><KeyInfo><o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><X509Data><X509IssuerSerial><X509IssuerName>CN=HNOPMOSS-HNOPMOSSDC1-CA, DC=HNOPMOSS, DC=COM</X509IssuerName><X509SerialNumber>2296976755542408161068403258569857451266408466</X509SerialNumber></X509IssuerSerial></X509Data></o:SecurityTokenReference></KeyInfo><e:CipherData><e:CipherValue>Yu+kA+IsmEywV/vY7ILtWYezR7H+nn0sxwQU+MB931zG2G4t5e1S5s7tuhnmOdq4DbTx26k7JiP/yJFGRgFhcKnCIOpNi9hQbFncG6qnFrOIPADKBQtUC++6S3K0obzjA/GTMiFr8IZBz5I3ghnm47GJBrgXf+oVglXiAR1r0brO5UPx/86r4V0EPCMWNlbzLGjZiZ+H7kX/2ong0RrwEgO90oSZuH9QaxiIO869z10x06yfcfWOQWWvf8HW+fdn0Az39ys6lwLoTQDOhcar9EtknZYOmS3YfcpmI2lV7nOFkYzqcLpL/Dl49nMSy+0XmThIMIOVptpQQbKIaXN1gQ==</e:CipherValue></e:CipherData></e:EncryptedKey></KeyInfo><xenc:CipherData><xenc:CipherValue>p4OGEI8DX+bZt+Guozq61CRp04uRtAvWrd8RGrM4B7tFSNR+TgTy9ljVjMCy+xmxZZxh6R305Aw5p6JHpAPrntfG9VueklqzeWPxJsjCd449QO3bMUflYrhPKQOgWOp+3gVHByHi1/qniYf2bSGqexWSSTwAX0w/qS2gENjPYR7iBCUPVghb/l87UfYgKLGPzQANKnmIezFNmqWdkcrse7wTmtxN/ldelDm7ZKHni8jD/h5B5gZvG45BBH4PpaXdG9cO/OjhgrBQepu/hBCGMJMIGGpXIRybTvONcnbIqLZh49RMQ1dO8N0UVN8ybFdISczTOnRl2jhMr5cruMXH6SVnj3QuMUqtsKDnZ+s5vdgyV4Awmq6c93JYPdzVHVg1ghcsWT/IDKyA9EoR8Sr168iC8H3Ys6zLf03WcyOSxJWtecmwhmAcGlot83L6eoJpwJSr5p9s6KP53oVe1uy/nI5rT3hxJyitkMZsCQhexyCyqQcL8biwqFzPBmaKuWGqRqA0J2tS9U894cY1h8FHNlaP1n9de9DdA4hdOwyaqYlG5TKwJVv1pbjoIrvm4xThDQ9zBZx1Whei+It+yI/m+ao6XGuwSbC3aF+Y1ojSlpBPAHlNVHXfX/2aJWFVgpcLrHH5Z5Z4T5i9cAD1Mk8ZmGO3Cj5SmvabphJS8uKDf2sJBUMmn+HYqZTSuFXZpfdaJpBo1Oy7nAYk7kZZ7HMhxdH7SXGGtHY6265uZgJxQ8vgRZj9FC5JGZwCS4b10i2Gh1AtGeH6Ly2yJi+T/NzsrrwJEQo61jZ9xyy6tqyAeEYag9zeB7Y95SPkmfcdonvpHyVoH0H9xXhEGfEGXW0I9jKHBcBzNHctUkKMcQrwmtMsxLfraqQARWBBUgRyF759yt3mtJL13yqWiBH9Pn7Y2JXP7jwcqnH6DG24/QK/Rw5LlaYdgQ8jd3kmyCUE/TDxMVY7At1PQnQZgqXZ+hc7h7OasO0ZW++IJn9UmRiI3MUjkhByk4l/4PKLtfUutnf2O43I3PfjnNfh33Ex+WgHPL16TY9pYKWp0K/W/iX4OldtpKqDZpkclDkwTAy+EMofNZDew59G4CHp3QvgTbNatT0yzz/v13lmpJTwNcISqzKIFWONdkZmlFRGNOy8Ko56GylTGfnDLwu0yThgkGXqQLOl4cP/Dv1Na/dCv93fXQ8MLX8nDgyiy9cPakPqNU/mLLblbT0Cm9i1NzlclkfMrgNXTeqlFEqndaWMP7gSO5AL+Yo9fC4bd/IwpvMgcag409FQf50ZxWdAVpNGDGOfcrs0ZvUHQp+/GhPSNgwERzdGs2TUBegwzCPNCV+M2WgBEDrMS63sTseRTjyvxuNYw9UwRwFRvaS75acySprijhxoiCtn5g7SglMuTkD5R8lsKjGHC77X1Oxzc6f7l+tScBehQA2wHusCg6+m+gXh2qtEby2/ygzzV95J/7TCpS9NoYMDZjghggXLku4GZU5lPGekEhlTVepkq+9q8y7Y6VuOcqsD/4/5+A0jq0svtaiMhGgE/F6ulOC8+YhP6dlKw8ypD/rcJrIiEIW8TRInOxBq8FlgujdFC2xsBGlZkXQjpRJ36giKQ2K01y/uWyZDhaHW4C/K0QMucdGFIyP7eHyijXaSEq1F3vb3qnrKb/iDQo0c2XhMn8udQBNmMCVi99xENKHZkYB4bIwA6gooZleKjWPDsrxau7XldXBxhhROHdMKOsTZYXq0ArbjU6bJ/kBa0d9f1a/ZOv8U8wTVdfnkoLe8acktZnJ5NqW1ZcAuJLoJGo91Urq7Bd6wXDhk0xB96Pfe1HPi2vuU/vSzE71mahX3NmMth0MrOjr8Cby6O9oFtHzkY1PFLtOOr2SPkUNpkp/7Z6c9XOb9DkJBCKYhTGYKVvTs0Ot00UUzaJFWsebk9xx/h414WqVdd0lKNOAcx+X7HuqNJPeaMm2ITq2KZQXzXPV2Juy8jeGD3yLFNmcF9cTemhwrAa23XvBlyiLYeY0q6agFECW1CjZkK8V1a+zJQgqUfSouhpWO7wzoL6Eu6dcqc8n9pZIvXco8Cms5U8y67aqWUN77cj6B5/GrhBBnDMj0XSKGkO221/3MM3tEf+ExXEsJ0QdqKyikKp90EHh4Rb1olR4lPwOxHrRkPO+Tr3A7haTj9C9KtaDRgqBWSlqCT+tp1AHQfg4Ojh2+s6s4fGGeajWRUwhLXDinxK5qhLwJsOPEf1G8YCIZLI5bKQ0eBDEoiwVal3OkOy6ygzL86jO0H4h0Tu+aIiUjKCYjXCt1hinTVfeU9RBxM67iep0Jhh23ut3U8r6deZLBF42mf6kBzJNyGXbxUTF6+KBc1YL701zmxwJFr81UXzF4feGbenx6NCpyn5QP5JhXdPjrPAy/n2o1MfCDSTEK5MrVUuRu43LJlewDTsCclleXUfdwRyErx6theBguYBdHyBb+Az0B8/XVfSt4XFVSOv1NoSnEOxu1ZEOSpcfy7JEovLTLkYiN+xEADek85G3yfCeKz5VcRcBSD8x9/4Wiev+iFEHA9EdIayz+tYFuWjf7KAHPGGZy4WJyiLe1KXy8HUtXNE4uOP5usDAYMhYVpQa8aRGXQeWP1wHnhPX/GvMWzO7mlH5Z7HswdiOlz1VKKBg3QGGf5UWSkQKN881qDqYHY8CBrQOVToBokbAQkd64P36n37cMPYAgd35LYK1WEjMgY8Z0rnLQVUtFVoUT7gh8hmLfjRkEFRePAC7rzzlB5KqxVgyiBHpSmLaEQBZkrq+/hmxLl4RdlJNsLjqi3upuLVgtyL03Ih/xuJrj/xWanJazRRGFmvjfsTdPSohKabYmvXoU8ZBJNVZ8MvH4G9Q2ac706lbFPD762+9jMqRdJdqDqwWjgzSTuw3Sm6RuKLhXjMAT4E2hkNgU3w5t9cEwzgj1QhcReWeodODV5DB+Lt5Amj7PKhFh78o1Fpbqg9kbR+De2z0GbUczoSIQI4gjs2gVTDfltbNvCzSEsVQ1BIb0leRUg6FR6jdg8ZZLdZGe96WuA+X5p48LHT3SkukPjj+uypI+X70E7uNuUHU9POaF7uBQoFU8+dgl/EIF/RQG0FjceS5e0wPc2mwxRSVkf6FX1eNZ+usEnYoo5vxuNieWLeTZnH8kpiBeYJnvsGxram6Ueeghlc/doYD97bVUwwmcRhFAnGfWomRGsIoespZgprqylD7swu5rAvJ/iHjb1l4b59xH9bRWNA4P/OvZACybxv7QQ9LWUKuYGgnazA5QZc6XV6E743NeLlk2jnPakEteJmojMEcVD5UntBiUcJFJx5BBme1xH5FggNa5SKgtqR/hc4R53bBRA3MD6FR4XBot9pRJRvZmXAJQOp9jR1n2bSfDEP2JQ4E6ldmVlPzTKy0AONmA9If0B7sC9/GZNvlkhxuFpetYLPi56VWaYvTuq9yWF2OyYvYQQ9R5o34bpUuA2C5RwW0/eTXwQv0jXSB0niu+msUB0kSU4/HpF6BaExNF/K0WbTVjWigQSGTtkwoVJZAOurDrLRzjzLA/eZOHhnB0XBggjI40JFld5lTpvK1ZVgxrUn8R2l4FFZBuqpOVmN0bFJL8UzXBvF/ugRv04tlY+LDFI2exii/n/MdKH2QonGIAHD9p2XhqTz7GM/yxhvNJ94AifBb0tvZIo6odPDZ9ElJ/JjKJlOP7zp4njrE65kPEAKzahAI3GsYot5IkuJOiFjfJBlmvAJpEb0IeIXMMPN6ZaMtrnvjCNqwdn4QhxEJO7MHx/9p3nIeLhdW2XxxgWqKg89i7TqRku8xF6P7nwvJOre6OhX2dc0yrBvzk4Qys9TV1EZr0KxlH5K2Vzk5PEfi5czsEex2EK3TdmlluSXmu0bAKWDfAUMLPbUd5p9NZ1UEVLlHBxrwQ2Tw0IXZGsYw1rLW1WV8UCi1oLd8Q6FqN0aS/y7V5hSNJQd+EG+gg4lpMPvuiwcZ90uhNCsVUJDX1vrHoZspVUi2YvaBxlFnftrryytpjdZr/u0OWjegzuPix6WHXG2CVSOXdKn4y4f6dII3p51xl/j4keqEKG5jtg3Ir4ypZuCSsmuOlkC0ZqeYpvHrXjUsFgWN7GtmmZAYcvMsGraFkiRGmTVmfPODtZjojEQ1uLk5j7QiquwBLnjQzRxE7J2jFYB4tzEoXqJIcpzOKR72cPxhF6QBPNawsT237hb+fr8ApUMAPvNK/eNE53TYga9gluQZU20aw2jwqiHWwdg6NAvm9IU4pLnZ6Dm9DyhOCUexdd3vK+pCE+Xd8e0kDxxuUuSZiEOR2+RMHGJpywcqTcqhY3t7Kj/Ha9S5TWzGFmLCEjk2qHlWJnxRydUt/iStj2npbevZTLxYWVjINnqdkHzK8JG8kP+sYZJiQ3dFkh6jrA9zM83u0gjjTZ3dL4nMCNsp05CvSO3wTKa4ccpJE90PLkyPkjHYbP7vIC3xJCMgdtPv/048YUessvt2PWvlktRCyH9f5Ym2QAhDliASppuvXqRbv1ak7A96pEwN6egRhRIkuoUDxEcJ9o2iNoAaTe18NlOn0zk5gO0m0SEseA3HmRwx6EiwzKJQU8rBntjGza2Qg1wncavlSP7nCGLDjihLKIicciokrYzUAH+xTOPrP1L65xrR0SPOB7u1mN0Mc0wE1F46k/eIDxmtYevqxhgwM5TIw0DJiET4z1n0Yn4naSCU5+2M92755BHCW3wTrQTpLE9jYkrqM6MdJeIlNdJDIJQc8yzE0tZBDWmEu62ZFEA0mL7iJb1/NGalQGazaSxwQu7xi/YRo8FvLCriMusNRaGcgBBKGbie8AlZMSWWoyyjdEm0HycCcnP19+2aPc79DzAGVpypuQIZn0x9ObgOQksIak33Tawt5PpEtaty4nw5D0KwH312mOenMD8308V6SAdO3oSTpf4pYtPzHPrdL2oqSKuFMlCK1wQQx7FN8VFRl9H4E5kI/Bsvafjme2dVInn0ocKFE0tVxfMWMSMeNL61EL8h4d149+O08rBrYdONGWrEjCdpxS5H/O6XR8xe9dQwHD40Os0cTVIOg6i7OS9O4bPLbny4hNP9DKcPBnrIQFe4V08ajJao2gvbzXtsFEfb32/dosISBGhpYcMOhHitPscyHoXEy+B78BWBCqrMxixQTihJAJVv1RjM0woo8H+YPh/Ekyb+xetPVin6eCtmzzjawQtV0FvakzlZVvaVT++HxVAMznd4C8cZ50uYHFhdnYEvC+TmghqQ4j/x0j5/SqNazT8hbRWLHiRpHnoUpTVBgOA50lHeihR1gJmER1t9mNvjkNslTmcON1qSk/bdYCbenOmvIOayx1XvgNnHMtdoKdfJ/OIdtAosJl6k1G7oBe2W7YoLzn+uIf41TkaPdR0zJHPhYVOtb0BxD4Plcu4Oo9JRYJ7RemROkcxgwdSKiO/oR33nJ+fpn9lMZwudX7K/SE15o7gpkSdnS3AMd6DFqk4h8hJwmmoK/R7cCYFAhrKJ4XRqxhkuq4dVMgNIjjG+2MQ==</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></trust:RequestedSecurityToken><trust:RequestedAttachedReference><o:SecurityTokenReference k:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" xmlns:k="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">_f5921fef-0700-4c2a-a064-48e9cdb1e765</o:KeyIdentifier></o:SecurityTokenReference></trust:RequestedAttachedReference><trust:RequestedUnattachedReference><o:SecurityTokenReference k:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" xmlns:k="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">_f5921fef-0700-4c2a-a064-48e9cdb1e765</o:KeyIdentifier></o:SecurityTokenReference></trust:RequestedUnattachedReference><trust:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</trust:TokenType><trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType><trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType></trust:RequestSecurityTokenResponse></trust:RequestSecurityTokenResponseCollection>

Could you tell me what difference between them?

...

I am facing some issues while creating AD Federation test lab on Windows server 2012 R2.

I am following the below link for establishing my test lab:

https://technet.microsoft.com/en-in/library/dn280939.aspx

For creating ssl certificate, I am following below link:

http://social.technet.microsoft.com/wiki/contents/articles/12485.configure-ssltls-on-a-web-site-in-the-domain-with-an-enterprise-ca.aspx

I have 3 servers:

1. Domain controller(hjs497-ad-d-1)

2. ADFS server(hjs497-ad-d-2)

3. Web server(hjs497-ad-d-3)

I have configured the certificate template for SSL certificate on Domain controller and then obtained a certificate for IIS( Web Server). It contain the Web server name in certificate.

Then I have exported that certificate and copied that on ADFS server machine and used it for configuring my ADFS server (as mention in Configure the federation server section of step 2).

Issue i am facing is that i am not able to access the AD FS server's metadata.

URL is https://hjs497-ad-d-3.adfsorg.com/federationmetadata/2007-06/federationmetadata.xml

Error: The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

And in brower, it is shown as Untrusted certificate.

Please help to fix this.

If you need more information please let me know.

Thanks

Sandeep Gupta

Hi there,

I'd like to migrate the authentification provider for a sharepoint farm from kerberos to an ADFS-server.

ADFS is up and running, I created claims rules for UPN and email adress, but it seems, that the UPN doesn't get evaluated during the logon process. 

Let's say the broadcast domains name is contoso.de

The primary mailadress-suffix is contoso-mail.de

I created a Trusted root authority in sharepoint like this:

New-SPTrustedRootAuthority -Name "my-adfs-provider" -Certificate $cert

$emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming

When I grant permissions in my sharepoint site to i:05.t|my-adfs-provider|user@contoso.de, the user can't log-in to this site. But when I grant permissions to i:05.t|my-adfs-provider|devmhda@contoso-mail.de,this user is able to log-on.

I guess on most setups primary mailadress and UPN may be the same, but not at a customers site. 

I also created a serverfarm from scratch in my lab and run into the same problem - evaluating the mail-claim works, but UPN does  not.

What may be wrong here?

Thanks in advance

Marcel

I have a client that I recently configured Single Sign-On with a third party external web app using AD FS.  The relying party trust has been configured on the AD FS farm.  The third party external web app redirects to the AD FS login successfully. When the users go in to logon they get the general AD FS error "An error occurred" page.  What other settings or configurations on AD FS do I need to pass this SAML token to the third party web app successfully?

• Activity ID: 00000000-0000-0000-0600-0080010000fb
• Error time: Wed, 02 Dec 2015 16:33:56 GMT
• Cookie: enabled
• User agent string: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.3; WOW64; Trident/7.0; Touch; .NET4.0E; .NET4.0C; Tablet PC 2.0; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3)

The Event Viewer shows EID 364

Hi,

We have a configuration with 2 ADFS 3.0 servers configured in NLB + 2 external ADFS Proxies (WAP) also in NLB.

When we try to configure the second ADFS Proxy using PowerShell we receive the folioing error:

"

Install-WebApplicationProxy : An error occurred when attempting to establish a trust relationship with the federation
service. Error: Unauthorized. Verify that the service account has administrative access on the target Federation
Server.
At line:1 char:1
+ Install-WebApplicationProxy -CertificateThumbprint xxxxxxxxxxxxxxxxxx ...+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Install-WebApplicationProxy], ProxyTrustException
    + FullyQualifiedErrorId : DeploymentTask,Microsoft.IdentityServer.Management.Proxy.Commands.InstallProxyCommand

"

The powershell command is:

 Install-WebApplicationProxy -CertificateThumbprint xxxxxxxxxx -FederationServiceName sts.xxxxxxx.com

The credentials that we enter are 100% valid, domain admin account.

Also the certificate thumbprint is valid, the certificate itself is also compliant, generated using Verisign services.

Everytime we enter the command specified above, ADFS Proxy generates a self signed certificate, using SubjectName = <computername>.

We found that a workaround will be to add in hosts file the  FederationServiceName sts.xxxxxxx.com to point to ADFS1 server IP.

After couple of days of investigating, we did't find any solution for our problem.

We tried:

Checking the certificates on ADFS and ADFS proxies (nets http show sslcert) and matching the results with: http://blogs.technet.com/b/applicationproxyblog/archive/2014/05/28/understanding-and-fixing-proxy-trust-ctl-issues-with-ad-fs-2012-r2-and-web-application-proxy.aspx

Everything looks perfect.

Reinstalling ADFS, WAP.

Please help.

Regards,

Andrei

I am trying to setup an application and when the user logs into the site they are prompted with a username password box and you can enter username/password and the box just keeps popping back up.  Using Chrome the user is redirected to a page on our ADFS Server and they can enter username/password it logs in.  Also I can disable Windows Integrated Authentication in IE and then the user can login and it gives them no prompt but takes them straight into the application.

Is this likely something on the ADFS Server of is there something I can the folks developing the application to take a look at?

A little new to this and trying to work my way through it.

Thanks

Mike

Dave

Hello

I have configured   adfs 2.0 SSO with Oracle Business Intelligence. When I am logged into my adfs application and then click into OBIEE Relying party trust few times I get following error in ADFS logs:

Encountered error during federation passive request. Additional Data Exception details: Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '16' seconds. Contact your administrator for details.   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.UpdateLoopDetectionCookie()   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SendSignInResponse(MSISSignInResponse response)

Hi all,

I have a question regarding ADFS 3 and multiple configured MFA providers. Let say I have a ADFS 3 server, configured with the Microsoft MFA plugin and SupplierX MFA plugin, both enabled in the Global Authentication Rules for users who want to authenticate to ADFS from the internet (WAP).

I have 2 usergroups (also represented by 2 groups in AD); 1 group user which have a Microsoft MFA token assigned and a group which have a token from SupplierX.

How does ADFS 3 work in this scenario? Does it show endusers a selection screen upon authentication in which the user has to tell ADFS if he wants to use MS MFA or SupplierX MFA? Or will ADFS requiere the user to enter both MFA tokens?

Robin

Find me on linkedin: http://nl.linkedin.com/in/tranet

HI 

We have a scenario where we want all users to use MFA when accessing published Office 365 services. However for internal users on work devices we want them to use certificates to enable seamless sign on. This works fine but means that users on home devices cannot access web mail etc. WE would like to deploy Azure MFA plugin so that they could receive a one-time password instead. If I install Azure MFA on premise and allow both certificate and Azure MFA as alternate methods of authentication, will the MFA prompt give the user the option to use MFA if they do not have a certificate? Or do I need to start publishign different claim rules for different MFA options?

Regards

How do you get the end user's ip address from ADFS?  The claims that I assumed you could retrieve them from return the ip of the load balancer or proxy server, not the end user.

http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip

http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

Any ideas?  

Keep receiving this error

"The target computer is not joined to a domain. Only machines that are joined to a domain can be members of a AD FS farm"

Server is a domain controller, so it's definitely joined to the domain. It's been rebooted.

Anyone got any ideas?