locked
ADFS 3.0 SSO login page customization RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have followed the following articles to customize the login page and it looks good so far.

    https://jasonomar.wordpress.com/2014/05/16/customizing-the-placeholder-on-the-adfs-3-0-login-page/

    https://technet.microsoft.com/en-us/library/dn280950(v=ws.11).aspx

    My Active Directory environment:

    We have two sets of users. One has a upn of "@company.com" and the other with an upn of "@company.local". The users with "@company.com" have emails in O365 (their UPN does not match email).

    My ADFS:

    We have two relying party trusts. One is O365 and the other is companyX. When I use O365 it directs me to the SSO page prepopulating the username field with my upn in the form "@company.com". The log in works.

    BUT when I get directed to the SSO page from companyX, the field is not populated. When I enter my samAccountname (not the upn) it fails to authenticate. To correct that I had to modify onload.js per the article below so that "@company.local" is added to username.

    https://technet.microsoft.com/en-us/library/dn636121(v=ws.11).aspx 

    Implementing the above works for companyX and I don't have to type the upn "@company.local". However, when I hit the submit/login button it shows "companyX.local\username" before signing me in. Is there a way for that to not show?

    Also, I am curious why the login works for O365 without implementing the changes from the last link above but not for companyX. I mean "@company.com" or just the accountname works for O365. For the companyX it has to be "@company.local" which is our local active directory domain (@company.com or just the username does not work).  

    Any insight is appreciated. Thanks!

    Thursday, August 18, 2016 7:26 PM

Answers

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    When you connect to Office 365, you type your login name (email address like) and you are being redirected to your ADFS server (as long as your register this domain in Azure AD as a federated domain). This is called the Home Realm Discovery. If you look closer at the URL you are being redirected, it looks like this:

    https://adfs.piaudonn.com/adfs/ls/?lc=1033&client-request-id=c22bbe8e-d839-4ed0-964e-4511215ffa47&username=lala%40piaudonn.com&wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=estsredirect%3d2%26estsrequest%3drQIIAeNisFLOKCkpKLbS1y_ILypJzNHLT0vLTE7VS87P1csvSs9MAbGKhLgE-vZpH7K8ccFvmp-roGL8L_dVjGo4dernJOalZOal6yUWF1RcYGTsYmIxNDA23sTE6uvs6-R5gmnCWblbTIL-RemeKeHFbqkpqUWJJZn5eY-YeEOLU4v883IqQ_KzU_MmMfPl5Kdn5sUXF6XFp-XklwMFgMYXJCaXxJdkJmenluxiVjEyNDVITkm01DW3SDbSNbE0TdW1MLMw0rW0SEwyNTUwM04zTDnAsiHkAovADxbGRaxAv_g9KWS_VbnKa9lVXpuykJPZp1j1wzNyMzKTgtz9LS3z3QOjKn2dClNLzZ0z3AOdLSrTjYydHAucDcO90nwDfG0trQx3cdoS53v7ksSi9NQSW1WjtJTUtMTSnBKwMAA1&popupui=

    You see the query string in the URL username=lala@piaudonn.com. This is consume by ADFS which will pre-poluate the username field of the form.

    Now I have questions. When you connect to the Application of CompanyX, do they have a Home Real Discovery the same way as Azure AD and Office 365? And if yes, can they just append whatever you type in their HRD in the URL that redirect the user to ADFS?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, August 23, 2016 1:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you Pierre.

    CompanyX has a link and it sends a SAML request.

    For CompanyX, I need to provide the local domain upn in order for SSO authentication to work, that is, it has to be username@company.local. I would want it to work with just the username.

    For O365 application, it can work with just the username or username@company.com upn. (company.com would be our external domain and company.local is internal Active Directory domain).

    Wednesday, August 24, 2016 8:46 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    The application should be agnostic of the username here. What matter is probably the claims you are sending. Or am I missing something?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, August 26, 2016 2:32 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Here is what happened.

    We have an adfs 2.0 sso that works for companyX by just entering the username. The config of this adfs 2.0 was exported and migrated over to adfs 3.0. The certs and federation name (everything) is the same in adfs 3.0 and was done as outlined in TechNet blog.

    But after the migration the SSO will not work by just entering the username. It needs to be in username@company.local or company.local\username format. Not sure what the difference here is between adfs 3.0 and 2.0 doing authentication differently when it is the same claims rule.

    Friday, August 26, 2016 2:42 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    This is just a JavaScript and can be customized like you have done, the onload.js.

    You can replace it with ...@something instead of something\... you can play with other JavaScript to kind of mask it, but what is the point, the users are complaining about this auto completion?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, August 29, 2016 12:55 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Onload.js was already modified to include "@company.local". This shows the "company.local\username" and the button is pressed. The behavior is not there with adfs 2.0. Also, with O365 the username@company.com carries over as username whereas it doesn't in adfs 2.0. In that sense ADFS 2.0 sso login page provided a sense of "uniformity".

    The goal is for users to type in just the username and password. It would be nice to not have the auto completion show in the username field.

    Tuesday, August 30, 2016 2:33 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    This is different from ADFS 2.x you are right.

    You can make it append the @something instead of the something\ if you'd like to.

    The bottom line is that you can probably use some JavaScript to make the trick. I saw customization such as hiding the default username field, setting the display to the normal one to hidden and some magic to copy one value into another in order not to show the appended something\. It did not work well depending on the browser. Preventing some external users from authenticating.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, August 31, 2016 1:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    It would be nice to have users enter the username only. It was so simple in ADFS 2.0. While the 3.0 comes with other features I think they made the SSO login part complicated.
    Tuesday, September 6, 2016 5:15 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    "It would be nice to have users enter the username only."

    That is what they do, the rest is automatically filed in without user interaction.

    Note that this is NOT SSO anyways since we are talking about web form. There is SSO regardless of the username format when you use Windows Integrated Authentication though.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, September 6, 2016 6:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Unlike many others out there our upn does not match the email. Not sure what implications this could have further down the road.

    The internal domain is company.local vs external company.com. Will "company.local" suffix work for any relying party? Because "company.com" suffix apparently does not work for this one relying party trust. In 2.0 only username need be entered for this relying party to work. For 3.0 "company.local" has to be suffixed. It seems to me that there could be problem with it if more relying party trust is added. Also, I am trying to figure out how to make that "company.local/username" part disappear after a user enters the credentials.

    Thursday, September 8, 2016 3:44 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Well, you could even use something different to login if you'd like, it's called Alternate Login ID. Maybe that'd help you.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, September 8, 2016 6:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Does it?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, September 13, 2016 3:55 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you Pierre.

    I have not tested it. Will give it a shot and update.

    Thursday, September 15, 2016 5:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    I had also tried with the same but it cause an error in ADFS 4.0.

    I have append the username in query parameter with SAML request. Please help me out for the same.

    Encountered error during federation passive request. 

    Additional Data 

    Protocol Name: 
    Saml 

    Relying Party: 
    urn:intlp*:*:com (Modified)

    Exception details: 
    Microsoft.IdentityModel.Protocols.XmlSignature.SignatureVerificationFailedException: MSIS0038: SAML Message has wrong signature. Issuer: 'urn:intlp*:*:com'. (Modified)
       at Microsoft.IdentityServer.Protocols.Saml.Contract.SamlContractUtility.CreateSamlMessage(MSISSamlBindingMessage message)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String& samlpSessionState, String& samlpAuthenticationProvider)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    Tuesday, December 24, 2019 1:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    This message has nothing to with a Javascript customization. Please create a new post.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Sunday, December 29, 2019 1:52 PM