0

Scenario

  1. User on AD client machine opens a browser and enters a https url to a service provider.

  2. Browser redirects to ADFS 3.0 IdP and the user is prompted to enter their AD user name and password.

  3. Browser redirects to the SP url and back to IdP six times until the following error is returned.

For a standard AD user

Activity ID: 00000000-0000-0000-1f00-0080000000f9
Relying party: SAM6
Error time: Thu, 01 Dec 2016 10:38:48 GMT
Cookie: enabled
User agent string: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0)
Gecko/20100101 Firefox/49.0

If the AD user attempts to login the following error appears

Activity ID: 00000000-0000-0000-1f00-0080000000f8
Relying party: SAM6
Error time: Thu, 01 Dec 2016 10:38:48 GMT
Cookie: enabled
User agent string: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0)
Gecko/20100101 Firefox/49.0

Google doesn't return any reports for these errors posting here to see if anyone has encountered these errors. Related results returned by Google have been checked.

GaryF
  • 21
  • 1
  • 3
  • Is the SAM6 your application which user attempted to login? Have you added the Relay Party Trust for SAM6 completed on your ADFS server? When you use a standard user (non-federated user) to login can you login successfully? – Jimmy Sun Dec 07 '16 at 10:18
  • SAM6 would be the service provider application and hence the relying party trust. The relying party trust has been created correctly, no typos etc. Users can log into AD correctly and if SAML authentication is disabled on the service provider application users can log in using SSO and Basic Autnentication – GaryF Dec 09 '16 at 09:14
  • Can you try to examine the Event log on the ADFS server? Path: Event Viewer->Application and Services logs->ADFS->Admin. – Jimmy Sun Dec 13 '16 at 03:53
  • According to the customer the error is the same in the event viewer – GaryF Dec 13 '16 at 17:05
  • Is the SAM6 application developed by yourself? If so, have you tried to check on the application side to see if this application could validate the token issued by ADFS successfully? – Jimmy Sun Dec 20 '16 at 10:33
  • Discovered what the issue was, once a user logged into the relying party trust server it began the SAML login procedure, and authenticated the user. However as part of the authentication process on the relying party trust server a id file needed to be accessed, which was causing another SAML assertion to be generated, once this requirement was removed the issue was resolved. – GaryF Jan 03 '17 at 14:26

1 Answers1

0

Discovered what the issue was, once a user attempted to log into the relying party trust server it began the SAML login procedure, and authenticated the user. However as part of the authentication process on the relying party trust server a id file needed to be accessed, which was causing another SAML assertion to be generated, once this requirement was removed the issue was resolved.

GaryF
  • 21
  • 1
  • 3