Our crowd server is authenticating to our active directory. We use a single domain name for all users (ie email@example.com). However, our google apps and mail is authenticating under our legacy company domain. By enabling SSO, will we be able to authenticate? Or will we be required to change all users to the legacy domain name to access email?
Also, if a user is outside the network and attempts to login to their google apps, will authentication be performed without sso (type in username and password). What affect will this have on password mismatches? Will the active directory password overwrite the google password if there is a varience? Thank you.
If You are using Crowd with LDAP backend and Google Apps - please check this add-on for Crowd:
What does it do - Crowd relies on Google Apps as user repository (with groups mapping), so:
- user can authenticate using credentials (password) from Google Apps
- user provisioning is only at google apps and no othe user repository, same for groups.
With this - Your Crowd can use Google Apps just like LDAP for handling user, groups of users, authorisation and authentication.
We are using this add-on in our company and we have disposed our LDAP :)
Hopefully I understand what you are after.
1. You user names must match in google apps and crowd. I'm unclear if when you say 'legacy domain' do they have different logins or are they all the same login just authenticating against a different directory?
2. Your google apps will always talk to crowd to authenticate users as you will be enabling SSO in google apps. So this also means that 'being outside' the network shouldn't matter as Google Apps will need to have access to crowd in order to perform SSO and authentication with Crowd
Thank you for your response. The user names are the same, they just have a different domain extension. (firstname.lastname@example.org vs jim@old_test.com). Our email accounts were created under the legacy company name, but our active directory is using the new domain name.
The problem I envision is a user authenticating to crowd, and attempting to access their email. There will be a mismatch in the domain name, causing a login failure. Additionally, the email passwords are not in sync with AD, so how would that be addressed?
1) Authenticating against an LDAP system with a different domain:
The actual implementation steps will vary based on your specific IdP / SSO provider, but on a general level you can achieve this by setting your NameID type to "unspecified" and returning only usernames, rather than full email addresses, in your SAML Responses. Additional configuration steps may be necessary in your specific SSO system.
2) Logging in from external networks:
By default, when SSO is turned on, users will always be served the SSO login page regardless of what network they are using to access Apps. If you want to restrict SSO logins to your corporate network, you can configure a network mask on the SSO setup page in your Apps Control Panel. Specifically, in the 'network masks' field of this page, you would enter the IP block (in CIDR notation) that is whitelisted for SSO access. If necessary, you can enter multiple IP blocks in this field.
Please note that as long as users' passwords are synced between your LDAP system and Google, users can bypass the SSO login system by signing in directly to Google. If you need to mandate SSO sign-ins, the users' actual Google Apps passwords must not be revealed (such that they are only given their LDAP/SSO passwords). This workflow may cause complications for mobile devices that do not support SSO authentication, so you should consider the consequences before making the decision of whether password syncing is right for your organization.
Hi community 👋, as every Monday we're bringing you a quick update on what happened in the Atlassian ecosystem last week. There were a few interesting events like for example the announcement of th...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events