AD FS Single Sign On - only working for 1 user

Hi,

Please verify user accounts are setup as specified in the following article.

https://support.office.com/en-gb/article/Add-users-individually-to-Office-365-Admin-Help-1970f7d6-03b5-442f-b385-5880b9c256ec

All the users are added to Office 365 by DirSync so all I had to do was activate the Office 365 license

They dont need license to login, but the ImmutableID and UPN needs to be properly configured (matching the on-prem value). Subdomains are treated differently/require additional configuration. So double-check on those. You can also try recreating the RPT as detailed here: https://support.microsoft.com/en-us/kb/2647048

If this doesnt help, capture the outgoing SAML token via Fiddler or similar tool end examine the content. Detailed steps can be found here: http://blogs.technet.com/b/askpfeplat/archive/2015/06/15/adfs-deep-dive-troubleshooting.aspx

Hi,

I have made some progress.

I have found the option "Edit Global Authentication Policy" in "Primary Authentication" in "Authentication Policy" in the AD FS Management Console


after I have enabled the "Forms Authentication" option in the Intranet section users within the company network could go to portal.office.com, enter their UPN jack@DomainName.com and the following pops up:


the user could then enter the network credentials and then be logged into office 365 - good result :)

But when a user that is not in the internal network (I do not know if this is just to do with the computer in the office being part of the domain) and the user goes to portal.office.com, enters their email addess jack@DomainName.com the following pops up:


and this is the details of the Token Signing Public Key Certificate:


I assume this is not how is it supposed to work?

can you suggest how to fix it

many thanks

jack

Seems like you have configured a second-factor auth for external users? You cannot use certificate-based auth with O365.

In "Edit Global Authentication Policy" I have not selected "Certificate Authentication" in either Extranet or Intranet options.

is there somewhere else I should look to disable the certificate authentication?

Those settings can also be configured on per RPT, so check (or just do a Get-AdfsRelyingPartyTrust | fl AdditionalAuthenticationRules).

This might also be pre-auth done on the proxy level. What are you using for the AD FS proxies, any TMGs or Netscaler, etc?

Vasil,

this is my result from the above command:

PS C:\Windows\system32> Get-AdfsRelyingPartyTrust | fl AdditionalAuthenticationR
ules
AdditionalAuthenticationRules :
AdditionalAuthenticationRules :
AdditionalAuthenticationRules :
PS C:\Windows\system32>

For the proxy I am using the "Web Application Proxy" in Server 2012 R2 - a VM that is not joined to the domain.


I was trying to look at the setting for this - but for the life of me I cannot find an option to see the setting of how I set it up

jack

OK so you dont seem to have any additional auth rules, so it leaves with the proxies (or some other device between the local AD FS server and the internet). For the WAP, do you remember how you published the AD FS rule? You can do a quick check if any pre-auth is set using this cmdlet:

Get-WebApplicationProxyApplication | fl Name,ExternalPreAuthentication

I ran: Get-WebApplicationProxyApplication | fl Name,ExternalPreAuthentication on the Web Application Proxy and it did not return any information

OK, so doesnt seem to be there as well. Any other devices between the Internet and the AD FS server that might be doing pre-auth?

Go to https://testconnectivity.microsoft.com/ and run the Office 365 Single Sign-On Test under the O365 tab. Post back the sanitized results here.

Vasil,

I had tried this before and there is no problem.

RCATestResult.html

this morning I tested a Windows computer that is on the internal company lan - but not joined to the domain - and after entering the email address at portal.office.com I was prompted for the domain username/password (in a dialogue box) and was able to log into office 365.

I also tried on a Mac that is joined to the domain - but I was not prompted for the username/password in a dialogue box and was not able to log into office 365

I appreciate your help

jack

OK, so if it's only on Mac, the issue is definitely not with any pre-auth settings or MFA as I though initially. There were some issues with Mac/iOS devices and AD FS 2.0, not sure if those apply to AD FS 3.0 though...

One thing that is known to cause issues with non-MS browsers is Extended Protection for Authentication (EPA) - check if it's enabled and temporary disable it. You can refer to method 3 in this article: https://support.microsoft.com/en-us/kb/2461628

I should do this on the AD FS server? not the "Web Application Proxy" Server?

I did not think AD FS on Server 2012 R2 used IIS?

thanks

jack

Use the PowerShell cmdlet:

Set-ADFSProperties –ExtendedProtectionTokenCheck None

Select allOpen in new window

Hi,

I did this and I am still unable to log into to single sign-on in the following situation:

- Within Company Network - Apple Macs
- Outside of the Company Network - Any computer.

within the company network, on a PC, I am prompted for the username / password in a dialogue box.

I have resolved the issue of behind asked to select a certificate while singing in - I disabled "Enable Device Authentication" in  "Edit Global Authentication Policy" in "Primary Authentication" in "Authentication Policy"

I do not know if this is useful, but these are my ADFS properties:

PS C:\Windows\system32> get-ADFSProperties


AcceptableIdentifiers                      : {}
AddProxyAuthorizationRules                 : exists([Type == "http://schemas.mi
                                             crosoft.com/ws/2008/06/identity/cl
                                             aims/groupsid", Value ==
                                             "S-1-5-32-544", Issuer =~ "^AD
                                             AUTHORITY$"]) => issue(Type = "htt
                                             p://schemas.microsoft.com/authoriz
                                             ation/claims/permit", Value =
                                             "true");
                                                         c:[Type == "http://sch
                                             emas.microsoft.com/ws/2008/06/iden
                                             tity/claims/primarysid", Issuer
                                             =~ "^AD AUTHORITY$" ]
                                                                    => issue(st
                                             ore="_ProxyCredentialStore",types=
                                             ("http://schemas.microsoft.com/aut
                                             horization/claims/permit"),query="
                                             isProxyTrustManagerSid({0})",
                                             param=c.Value );
                                                         c:[Type == "http://sch
                                             emas.microsoft.com/ws/2008/06/iden
                                             tity/claims/proxytrustid", Issuer
                                             =~ "^SELF AUTHORITY$" ]
                                                                    => issue(st
                                             ore="_ProxyCredentialStore",types=
                                             ("http://schemas.microsoft.com/aut
                                             horization/claims/permit"),query="
                                             isProxyTrustProvisioned({0})",
                                             param=c.Value );
ArtifactDbConnection                       : Data
                                             Source=SQLSERVER2\ADFS;Initial Cat
                                             alog=AdfsArtifactStore;Integrated
                                             Security=True;Min Pool Size=20
AuthenticationContextOrder                 : {urn:oasis:names:tc:SAML:2.0:ac:cl
                                             asses:Password, urn:oasis:names:tc
                                             :SAML:2.0:ac:classes:PasswordProte
                                             ctedTransport, urn:oasis:names:tc:
                                             SAML:2.0:ac:classes:TLSClient, urn
                                             :oasis:names:tc:SAML:2.0:ac:classe
                                             s:X509...}
AutoCertificateRollover                    : True
CertificateCriticalThreshold               : 2
CertificateDuration                        : 365
CertificateGenerationThreshold             : 20
CertificatePromotionThreshold              : 5
CertificateRolloverInterval                : 720
CertificateSharingContainer                : CN=6fbeafbf-74ff-4c01-ad64-0446fba
                                             8abca,CN=ADFS,CN=Microsoft,CN=Prog
                                             ram Data,DC=DomainName,DC=local
CertificateThresholdMultiplier             : 1440
ClientCertRevocationCheck                  : None
ContactPerson                              : Microsoft.IdentityServer.Managemen
                                             t.Resources.ContactPerson
DisplayName                                : Company Name
IntranetUseLocalClaimsProvider             : False
ExtendedProtectionTokenCheck               : None
FederationPassiveAddress                   : /adfs/ls/
HostName                                   : fs.DomainName.co.uk
HttpPort                                   : 80
HttpsPort                                  : 443
TlsClientPort                              : 49443
Identifier                                 : http://fs.DomainName.co.uk/adfs
                                             /services/trust
InstalledLanguage                          : en-US
LogLevel                                   : {Errors, Information, Verbose,
                                             Warnings}
MonitoringInterval                         : 1440
NetTcpPort                                 : 1501
NtlmOnlySupportedClientAtProxy             : True
OrganizationInfo                           :
PreventTokenReplays                        : True
ProxyTrustTokenLifetime                    : 21600
ReplayCacheExpirationInterval              : 60
SignedSamlRequestsRequired                 : False
SamlMessageDeliveryWindow                  : 5
SignSamlAuthnRequests                      : False
SsoLifetime                                : 480
PersistentSsoLifetimeMins                  : 10080
KmsiLifetimeMins                           : 1440
PersistentSsoEnabled                       : True
PersistentSsoCutoffTime                    : 01/01/0001 00:00:00
KmsiEnabled                                : False
LoopDetectionEnabled                       : True
LoopDetectionTimeIntervalInSeconds         : 20
LoopDetectionMaximumTokensIssuedInInterval : 5
PasswordValidationDelayInMinutes           : 60
SendClientRequestIdAsQueryStringParameter  : False
WIASupportedUserAgents                     : {MSAuthHost/1.0/In-Domain, MSIE
                                             6.0, MSIE 7.0, MSIE 8.0...}
ExtranetLockoutThreshold                   : 2147483647
ExtranetLockoutEnabled                     : False
ExtranetObservationWindow                  : 00:30:00



PS C:\Windows\system32>


PS C:\Windows\system32> Get-ADFSProperties | Select  -ExpandProperty WIASupporte
dUserAgents
MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client
PS C:\Windows\system32>

I also ran this command to add different browser support:

Set-ADFSProperties -WIASupportedUserAgents @("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0", "Safari/6.0", "Safari/7.0", "Safari/8.0")

On the mac I have been able to activate office with the 1 user account that was working at the start.

If you mean true seamless SSO experience, this is only possible for domain joined machines. To enable it, make sure Windows Authentication is selected in the global auth policy, that the AD FS FQDN is added to Local sites in IE settings and WIA is enabled for the zone. The behavior and requirements for both inside and outside the corp network are explained in details here: http://blogs.technet.com/b/abizerh/archive/2013/04/11/more-information-about-sso-experience-when-authenticating-via-adfs.aspx

I found this article which described a similar issue to what I am experiencing in that only administrators could log into https://fs.DomainName.com/adfs/ls/IdpInitiatedSignon.aspx from outside my company network:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/198fa6fe-050f-415d-88d9-ca2f7141041f/adfs-2012-r2-fails-to-login-domain-users?forum=winserver8gen

one user wrote:

"update on this issue. I figured out what was causing this. I use a managed service account for the ADFS service, because this is best practice.

It looks like the Managed Service account has too less permission to read the user properties to let them authenticate. When I add the managed service account and give it read permission to a user that didn't work I can logon successfully. I can of course add this right to the whole OU where the users are in to fix it for all users.


Is this a security issue? Give i now to less or too much security too this account. Can someone give me advise what permissions to give.

Regards"

so I added read permission for the Managed Service Account DomainName\ADFS2SVC to a user that could not log into https://fs.DomainName.com/adfs/ls/IdpInitiatedSignon.aspx externally - and that user was then able to log in.

Does it surprise you to read this?

what is best practice for giving permissions to the DomainName\ADFS2SVC?

Another thing suggested in the article is to add the Managed Service Account DomainName\ADFS2SVC to the Windows Authorization Access Group

your thoughts would be appreciated

many thanks

jack

Nice catch, definitely havent seen this one before. Not sure why "Authenticated Users" was missing from the "Pre-Windows 2000 Compatible Access" group in their case, it's present on all the ADs I manage. But check for that, and fix it if needed. Same for the "Windows Authorization Access" group and the gmsa.

Vasil,

thank-you for your reply.

to confirm my understanding, am I to add the Managed Service Account DomainName\ADFS2SVC to both the following Security Groups:
- Pre-Windows 2000 Compatible Access
- Windows Authorization Access


at the moment it is not in either

or am I supposed to add Authenticated Users to these groups?

many thanks

jack

and I can ignore the Windows Authorization Access group?

Well it might not be needed. As I said, I havent actually encountered this issue before, so I cannot speak from experience. My idea is - take it one step at a time, as however small those actions are they do introduce changes in the environment, so avoid doing changes you dont really need.

Vasil,

it looks like just adding "Authenticated Users" to the "Pre-Windows 2000 Compatible Access" was enough to let people log in

thank-you for your help!

jack

I really appreciate your help in working through the problem with me and getting to the answer

In all fairness, you found the answer :)

well.. I had found it before I started writing on this post - but just because it was only somewhere does not mean it was a safe thing to do :)