No one has responded to this discussion for at least a year, so this information may be out of date. If you're looking for information about this topic, please search for a more recent discussion or post a new question.

ID Fed Feedback Please

  • We're seeing lots of Forum and Support activity around ID Federation. We know that this is one of the most complex areas in Office 365 and we'd like to know what issues you're running into and any suggestions you have about how to improve your experience with this technology. Please reply to this post and let us know your thoughts.

    I'll post a similar request in the File bugs and feedback forum, but let's make this the primary location for this discussion.


    1 out of 1 people found this post helpful.

  • Aside from the technical complexity of getting ID Federation set up correctly, the most glaring issue is the user experience.

    The experience for a web user logging in is really poorOur testers have taken to calling it "double sign on" instead of "single sign on" because you have to type your user name twice every time you log in. Our instructions for signing on currently look something like:

      - go to ""

      - type your login name ( in the login box

      - press TAB

      - wait for the screen to redraw

      - click on the link that says "sign in at"

      - type your login name again and enter your password


    That's about 3 steps too many.

    It seems that the redirection to ADFS is attempting to pass along the username so the user doesn't have to retype it (the redirect URL includes the login name), but for whatever reason the ADFS server isn't picking up that information and using it to pre-populate the login form. 

    Obviously, all the portal page is doing is using the login name to identify the federated domain and redirect the browser there.

    One way to mitigate the situation would be to provide a simple way to have a per-domain portal page address ("") that would send the user to straight to ADFS without them having to type a domain name. (And after ADFS login, they would be redirected back to "").

  • Thanks David.  Yes you can create what is know as a "IdP initiated sign in" or "smart link" that is a vanity URL that will take you directly to your ADFS server, and thus bypass the first login page (where we perform home realm discovery).  Unfortunately it's a little involved.  I will be posting a wiki on this topic - so stay tuned.

    I have a question for you:

    • Is this experience what you are getting when the user is signing in the experience you get when on-premise?  The prompt that you see, is it a windows security dialog?

    If so, then this can be removed with a browser setting.  Which browser are you using?

    In IE, go to Tools->Options and select Security.  Then select "Trusted Sites" and add the site to your trusted sites.  Hopefully this will get rid of the windows security dialog that asks for your credential.

    Please let me know if this helps,


  • I would have to agree with David.  When logging in through the ADFS Proxy you must enter your username at then click the link to get redirected, then enter the username and password again.  Too many steps.  Internal machines are able to take advantage of "automatic logon" in IE when the adfs URL is added to trusted sites.  I would be very interested to find out how to create a redirected login page as you suggest.

  • I'd suggest the documentation around this needs some improvement.

    Taking the 'default' route through the Docs installs ADFS 2.0, but as far as I can tell does not run the intial configuration wizard !

    If you do then manually run this wizard you are into another frequently asked question about 'internal or external' certificates !

    A complete step-by-step guide is needed.

    Regards, Graham

  • Another catch-22 in the setup or documentation - you are advised to setup federation before directory sync.

    However, to verify federation is working, it replies on Directory Sync to perform the verification !

  • You can verify that ID federation is working before installing DirSync - but it is a little bit ugly.

    Simply log on to your desktop machine as the user you want to test federation with.  Open IE and go to  At the O365 login page type the UPN of the user - first verification is that when you tab to the password field, this should gray out and you should see "Sign in at ... <your federation server>".  This means that your domain (i.e. the domain suffix of the UPN you typed) is indeed federated with Office 365.

    Next click on the "SIgn in at..." link.  This will direct the browaer to your AD FS 2.0 server.  If you are within your corporate network you should be seamlessly redirected (after authentication) back to the O365 login page (blink and you might miss it) and then on to the O365 portal.  If the portal says "Access denied" it mean you were authenticated BUT you don't have access (because this user has not yet been provisioned to your tenant/company in O365.  Once you run DirSync and assign users licenses, they should also get access.

    Hope this helps


  • We've also put a bunch of documents into our SSO/Identity Federation wiki site.  Please check it out and let us know what you think.  I would love to see some comments on some of the wiki articles that we've posted.



  • I've spoken to the AD FS team about this, and we're looking in to this (populating the user name into the ADFS proxy login page) to see if this can be fixed for a later release.

    I'll post a wiki shortly on the redirected login.

    NOTE:  One thing you can try now for more seamless sign in (when on a domain joined machine inside the corporate network).  Try going to<your federated domain> (where you replace <your federated domain> with the name of the domain you federated with O365).  If it works correctly you should just land straight in the OWA mailbox without any prompts or seeing the O365 login page.  (I demoed this behavior at TechEd Europe last year).

  • Please see the following code snippet that can be used to customize the forms login page on the ADFS proxy to grab the username that was entered on the Office 365 login service (as part of home realm discovery).

    Please open the FormSignIn.aspx.cs page (under the inetpub\adfs\ls folder) and update it as below (replacing the first half of the page.  Make sure that you include all the extra "using" statements too...

    using System;

    using System.Web;

    using System.Collections.Specialized;

    using Microsoft.IdentityServer.Web;

    using Microsoft.IdentityServer.Web.UI;


    /// <summary>

    /// Attempts to authenticate the user via HTTP Forms Authentication.

    /// </summary>

    public partial class FormsSignIn : FormsLoginPage


        protected void Page_Load( object sender, EventArgs e )


            string url = Context.Request.Url.AbsoluteUri;

            NameValueCollection parameters = HttpUtility.ParseQueryString(url);

            string userIdentity = parameters["username"];

            if (!String.IsNullOrEmpty(userIdentity))


                UsernameTextBox.Text = userIdentity;



    ... <rest code remains the same>

    You should now start seeing the username populated into the ADFS proxy login page.

  • I just posted an article on smart links (or IdP initiated sign in).  You can find it here:

    Hope this helps,


  • +1 (regarding a somewhat cumbersome AD FS installation procedure).


    I'd also (reaaaaaaaaaaly) would appreciate if future releases of AD FS would support several "UPN-domains" within the same AD FS infrastructure.


    Example: Within a AD forest with several UPN suffixes (e.g., and and an Exchange-org with several accepted domains with EAP's, with UPN's such as this: 


    the "Domain-corp" in this example has to (as I understand it, feel free to correct me) implement a total of 12 (!) AD FS-servers: 6 AD FS Proxies + 6 AD FS servers (2 in each AD FS Proxy Farm + 2 in each "internal" AD FS Farm * 3 ( for each domain suffix (.com, .se, .org)).



  • 1.  The double-sign in.  I'm going to attempt the fix above, but I'm not really sure if I should be editing it on my proxy or on my internal machine.

    2.  Rich clients/IE/etc are not accepting the single sign on.  Outlook and Lync still prompt for credentials and IE still takes me to the adfs login page.  Right now, all SSO is doing for me is allowing passwords to stay in sync--which is worth it in itself.

    3. No clear guide on customizing the adfs page.  I've beat it into my users heads that they don't put their company credentials on anything without a company logo.  I've tried the msdn article for adding a logo to the adfs page, but it just doesn't work.

    4. The documentation is pretty clear, but it could be better.  There's a lot of ambiguity as to whether you're supposed to be performing a step on the proxy or on the internal ADFS box.

    5. No documentation on how to configure it with ISA/TMG.  Right now, I've only got a single external proxy because NLB was not playing nicely with TMG.  I was kind of hoping there'd be more information on getting a MS product to work with an MS service.

  •  @

    regarding issue 3: you can modify the StyleSheet.css-file in the /MasterPages-folder to include a logo pic. The "section" to modify is the . header, for example something like this:


        color: transparent !important;
        padding: 8px 0 5px 0;
        margin-top: 50px;
        margin-bottom: 20px;
        font-size: 0px !important;
        background: transparent url(/adfs/ls/[name_of_logo_pic]) no-repeat;
        width: 227px;
        height: 71px;


    In the above scenario the [name_of_logo_pic]-file resides in the ls-folder (most likely path:  C:\inetpub\adfs\ls).

    Remember to:

    1. Make a backup of the css-file before you make the changes
    2. Don't blame me if something usual..."this is as is...yada yada...bla bla bla" ;)
    3. Make the change to all of your AD FS servers (internal and proxies)...after you have verified successful behaviour
    4. Have a beer or two handy...