Allow cross domain Single Sign-on on multisite

I had Domain Mapping but deactivate it due to an issue with wildcard SSL certificate. And use the built-in WordPress mapping option.

The issue is when user login to main site, they’re not automatically logged in to the other sites. Which make it impossible to comment on the mapped subsites.

For example, if user is logged in to, they need to login again to to have access. While they still have access the the non-mapped subsites(like

The question is, how can I force Single sign-on for all the domain and mapped one?

  • Ash
    • WordPress Hacker

    Hello jcnjr

    When you use default domain mapping in wordpress multisite, then single sign on won’t work, there is not much we can do here, I am afraid :slight_frown:

    I had Domain Mapping but deactivate it due to an issue with wildcard SSL certificate.

    About the original issue you were having with our domain mapping plugin, would you please let me know more details about it so that we can try to fix that and if we can, then you don’t need to use he default mapping option?

    Let us know please.

    Have a nice day!



  • jcnjr
    • HummingBird

    Thank you for the prompt reply Ash. This is seriously unfortunate to hear.

    Since Domain Mapping had functionality built in to log users into all sites, perhaps might WPMU Dev consider developing a more simple plugin just to address the single sign-on issue for WP native domain mapping.

    There is apparently a widely known conflict with WPMUDev Domain Mapping and Really Simple SSL Pro Multisite as described here:

    With Domain Mapping activated, we also encountered an infinite redirect loop when attempting to log in to site dashboards. Most common symptoms: the login screen would appear again after signing in, or nothing would happen when clicking Submit on signup form.

    Regardless, I need to get this sorted out. I’ll gladly go back to using the Domain Mapping plugin if I can get help resolving the redirect issue.

    And FYI: The log-in issue was only noticed after activating Hummingbird, which was done shortly after implementing SSL. Any chance that could be causing the problem?

    Thanks again!

  • jcnjr
    • HummingBird

    The log-in issue was only noticed after activating Hummingbird

    Regarding Hummingbird…

    Would Hummingbird speed up any delay that may have been causing the redirect loop?

    I’m wondering if now that Humming bird is active, response may be quicker, resolving the loop, but I am not exactly certain how HB comes into play for the dashboard and log-in pages.

    Reverting to the Domain Mapping plugin is time consuming and interrupts service while DNS propagates, so I’m just looking for feedback before doing so.


  • jcnjr
    • HummingBird


    Thank you for your help in getting this resolved.

    Since you suggest that Domain Mapping is the only way to provide a single sign-on for all sites, I have once again network-activated that plugin and configured the settings as they were before.

    Users are still not able to remain logged in when visiting the mapped domain site. Since we only have a couple admins, I’ll deal with the redirect loop issue later if that persists. I did already encounter it when trying to log into the mapped domain /wp-admin.

    So, we are back where we started, even with the Domain Mapping plugin method to map domain.


    1. User logs into

    2. User visits (mapped via plugin to

    3. User is logged out and cannot comment on posts without providing email


    1. Domain Mapping network-activated

    2. sunrise.php moved to /wp-content

    3. sunrise defined ON in wp-config

    4. SiteURL reset to

    5. Domain added to Mapping tab on subsite

    6. Domain health is “Valid”

    7. Domain is pointed to same Name Server of Host (root domain) at Registrar

    8. Add-On Domain created via cPanel for

    9. Network Setting: Cross-domain autologin set to Yes

    10. Load Cross-domain autologin asynchronously box is checked

    11. Administration mapping and Log-in mapping both set to domain entered by the user

    This is the way we had it working before attempting the native domain mapping method.

    Where do we go from here???

  • jcnjr
    • HummingBird

    FYI: Thinking this may have been waiting on DNS propagation, I waited and have now confirmed the issue persist.

    Also confirmed the redirect loop persists when attempting to load the mapped.domain/wp-admin now that Domain Mapping is active again. If I visit the URL changes to /wp-login.php?… but nothing ever displayes because the page just keeps reloading again, and again and again, and…

    Any suggestions for getting this sorted out is greatly appreciated.

    #1 priority is to get the cross domain log-in working again for all users.

    For now, admins can visit the dashboard via the unmapped admin URL.

  • Ash
    • WordPress Hacker

    Hello jcnjr

    Thanks a lot for detailed comments.

    When you activated domain mapping plugin again, did you remove the mapped domains from Network Admin > Sites > Edit a site and added them in subsite admin > Tools > Domain Mapping?

    Also, would you please enable support access so that I can check? Please follow this article to enable support access:

    Have a nice day!



  • jcnjr
    • HummingBird

    Ash said:

    did you remove the mapped domains from Network Admin

    Thanks for checking in.

    Yes, I did edit the site from Network Admin -> Sites to restore the subdomain ( as the Site Url.

    I have also just deleted the mapped domain ( from Network Admin -> Settings -> Domain Mapping for the site I then attempted to add the mapped domain ( again from the subsite ( Admin -> Tools -> Domain Mapping but now get the attached DNS error. So now we are stuck with the unmapped an unavailable site! <sigh> So now our Foundation site is offline, eventually redirecting to the primary domain.

    I'm hoping this is temporary, and will continue trying to remap the domain.

    Support Access has been granted again.

  • Ash
    • WordPress Hacker

    When you activate Domain Mapping plugin, you must move the sunrise.php file in the proper place and set the define in wp-config.php as per the instruction in domain mapping page:

    Please copy the sunrise.php from your plugin folder /home/tripawds/public_html/wp-content/plugins/domain-mapping/sunrise.php into /home/tripawds/public_html/wp-content/sunrise.php.

    In your /home/tripawds/public_html/wp-config.php file please uncomment or add (if not available) the following code: define( ‘SUNRISE’, ‘on’ );

    So, move the sunrise.php from your plugin folder /home/tripawds/public_html/wp-content/plugins/domain-mapping/sunrise.php into /home/tripawds/public_html/wp-content/sunrise.php

    And add the following line in wp-config.php before “/*That’s all…..*/” message

    define( 'SUNRISE', 'on' );

    Let us know how it goes. Have a nice day!



  • jcnjr
    • HummingBird



    you must move the sunrise.php file in the proper place and set the define in wp-config.php

    I know, I have done all that.

    I have had to revert to the native WP domain mapping method, after attempting the plugin again resulting in the mapped sites being offline far too long. I will open this ticket backup if I ever try again, and will hope that WordPress builds in some sort of cross domain cookie magic since they have added the mapping option…why this option hasn’t been added yet baffles me, since it can clearly be done with the plugin.

    Thanks anyway.

  • Josh
    • Design Lord, Child of Thor

    I had the exact same problem, and have managed to solve it. We also were using the Really Simple SSL plugin and thought that was the issue causing the reload (because it put things into a reload loop whenever we turned on the network-wide SSL), but that wasn’t actually the problem.

    The problem was that our network foundation domain had “www” in the domain. This is seen in the wp-config file in this line:

    define('DOMAIN_CURRENT_SITE', '');

    The reason this causes problems is that the cookies that enable cross-domain login to work get set with this domain as the cookie. If the cookie was set as “” then all subdomains (and subsites) can access that cookie. But instead the cookie was being set as “” – which is inaccessible for the subdomains.

    My understanding is that it is a really bad idea to change the DOMAIN_CURRENT_SITE setting once the multisite network is established, as it will mess a bunch of things up.

    So instead we were able to solve the problem by adding this one line to our wp-config file:

    define('COOKIE_DOMAIN', '');

    And we removed these 3 lines:

    define('ADMIN_COOKIE_PATH', '/');
    define('COOKIEPATH', '');
    define('SITECOOKIEPATH', '');

    When those 3 lines were in there, alongside the COOKIE_DOMAIN setting, we had the reload problem.

    So removing those 3 lines, plus adding in the COOKIE_DOMAIN setting is what solved it for us. With this in place the cross-domain login works fine, including for mapped domains. And the Really Simple SSL works fine now too. (Except for when we try the network-wide SSL setting … that still causes a different loop. Haven’t managed to fix that yet, so we’re just using the Per-Site setting for SSL).

    I hope this helps someone else!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.