jackbenson
asked on
AD FS Single Sign On - only working for 1 user
Hi,
I have set up SSO for use with office 365 and Dropbox.
When I was testing both Office 365 and Dropbox with my domain account it was working fine.
for Office 365 I would go to portal.office.com and enter my work email address.
I would get re-directed to fs.DomainName.com and I would enter my domain password and I would be logged into office 365.
I assumed all was fine so I allocated licenses to my 20 users in office 365 but when they went to sign in at portal.office.com and were re-directed to fs.DomainName.com - entered their correct password - the page would just submit back to itself.
if the user entered the wrong domain password at fs.DomainName.com then it would give the error that the password is wrong. When the password was correct it would just post back to itself with no error message.
I cannot work out why this is happening.
any help would be appreciated.
thanks
jack
I have set up SSO for use with office 365 and Dropbox.
When I was testing both Office 365 and Dropbox with my domain account it was working fine.
for Office 365 I would go to portal.office.com and enter my work email address.
I would get re-directed to fs.DomainName.com and I would enter my domain password and I would be logged into office 365.
I assumed all was fine so I allocated licenses to my 20 users in office 365 but when they went to sign in at portal.office.com and were re-directed to fs.DomainName.com - entered their correct password - the page would just submit back to itself.
if the user entered the wrong domain password at fs.DomainName.com then it would give the error that the password is wrong. When the password was correct it would just post back to itself with no error message.
I cannot work out why this is happening.
any help would be appreciated.
thanks
jack
ASKER
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
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
ASKER
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
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.
ASKER
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?
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 AdditionalAuthenticationRu les).
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?
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?
ASKER
Vasil,
this is my result from the above command:
PS C:\Windows\system32> Get-AdfsRelyingPartyTrust | fl AdditionalAuthenticationR
ules
AdditionalAuthenticationRu les :
AdditionalAuthenticationRu les :
AdditionalAuthenticationRu les :
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
this is my result from the above command:
PS C:\Windows\system32> Get-AdfsRelyingPartyTrust | fl AdditionalAuthenticationR
ules
AdditionalAuthenticationRu
AdditionalAuthenticationRu
AdditionalAuthenticationRu
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-WebApplicationProxyApp lication | fl Name,ExternalPreAuthentica tion
Get-WebApplicationProxyApp
ASKER
I ran: Get-WebApplicationProxyApp lication | fl Name,ExternalPreAuthentica tion 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.
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.
ASKER
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
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
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
ASKER
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
I did not think AD FS on Server 2012 R2 used IIS?
thanks
jack
Use the PowerShell cmdlet:
Set-ADFSProperties –ExtendedProtectionTokenCheck None
ASKER
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/ide ntity/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;Ini tial Cat
alog=AdfsArtifactStore;Int egrated
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:Passw ordProte
ctedTransport, urn:oasis:names:tc:
SAML:2.0:ac:classes:TLSCli ent, urn
:oasis:names:tc:SAML:2.0:a c:classe
s:X509...}
AutoCertificateRollover : True
CertificateCriticalThresho ld : 2
CertificateDuration : 365
CertificateGenerationThres hold : 20
CertificatePromotionThresh old : 5
CertificateRolloverInterva l : 720
CertificateSharingContaine r : CN=6fbeafbf-74ff-4c01-ad64 -0446fba
8abca,CN=ADFS,CN=Microsoft ,CN=Prog
ram Data,DC=DomainName,DC=loca l
CertificateThresholdMultip lier : 1440
ClientCertRevocationCheck : None
ContactPerson : Microsoft.IdentityServer.M anagemen
t.Resources.ContactPerson
DisplayName : Company Name
IntranetUseLocalClaimsProv ider : False
ExtendedProtectionTokenChe ck : 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
NtlmOnlySupportedClientAtP roxy : True
OrganizationInfo :
PreventTokenReplays : True
ProxyTrustTokenLifetime : 21600
ReplayCacheExpirationInter val : 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
LoopDetectionTimeIntervalI nSeconds : 20
LoopDetectionMaximumTokens IssuedInIn terval : 5
PasswordValidationDelayInM inutes : 60
SendClientRequestIdAsQuery StringPara meter : 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 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
crosoft.com/ws/2008/06/ide
aims/groupsid", Value ==
"S-1-5-32-544", Issuer =~ "^AD
AUTHORITY$"]) => issue(Type = "htt
p://schemas.microsoft.com/
ation/claims/permit", Value =
"true");
c:[Type == "http://sch
emas.microsoft.com/ws/2008
tity/claims/primarysid", Issuer
=~ "^AD AUTHORITY$" ]
=> issue(st
ore="_ProxyCredentialStore
("http://schemas.microsoft.com/aut
horization/claims/permit")
isProxyTrustManagerSid({0}
param=c.Value );
c:[Type == "http://sch
emas.microsoft.com/ws/2008
tity/claims/proxytrustid",
=~ "^SELF AUTHORITY$" ]
=> issue(st
ore="_ProxyCredentialStore
("http://schemas.microsoft.com/aut
horization/claims/permit")
isProxyTrustProvisioned({0
param=c.Value );
ArtifactDbConnection : Data
Source=SQLSERVER2\ADFS;Ini
alog=AdfsArtifactStore;Int
Security=True;Min Pool Size=20
AuthenticationContextOrder
asses:Password, urn:oasis:names:tc
:SAML:2.0:ac:classes:Passw
ctedTransport, urn:oasis:names:tc:
SAML:2.0:ac:classes:TLSCli
:oasis:names:tc:SAML:2.0:a
s:X509...}
AutoCertificateRollover : True
CertificateCriticalThresho
CertificateDuration : 365
CertificateGenerationThres
CertificatePromotionThresh
CertificateRolloverInterva
CertificateSharingContaine
8abca,CN=ADFS,CN=Microsoft
ram Data,DC=DomainName,DC=loca
CertificateThresholdMultip
ClientCertRevocationCheck : None
ContactPerson : Microsoft.IdentityServer.M
t.Resources.ContactPerson
DisplayName : Company Name
IntranetUseLocalClaimsProv
ExtendedProtectionTokenChe
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
NtlmOnlySupportedClientAtP
OrganizationInfo :
PreventTokenReplays : True
ProxyTrustTokenLifetime : 21600
ReplayCacheExpirationInter
SignedSamlRequestsRequired
SamlMessageDeliveryWindow : 5
SignSamlAuthnRequests : False
SsoLifetime : 480
PersistentSsoLifetimeMins : 10080
KmsiLifetimeMins : 1440
PersistentSsoEnabled : True
PersistentSsoCutoffTime : 01/01/0001 00:00:00
KmsiEnabled : False
LoopDetectionEnabled : True
LoopDetectionTimeIntervalI
LoopDetectionMaximumTokens
PasswordValidationDelayInM
SendClientRequestIdAsQuery
WIASupportedUserAgents : {MSAuthHost/1.0/In-Domain,
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>
ASKER
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.
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
ASKER
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
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.
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
ASKER
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
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
ASKER
I really appreciate your help in working through the problem with me and getting to the answer
In all fairness, you found the answer :)
ASKER
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 :)
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