Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ask Slashdot: Single Sign-On To Link Google Apps and Active Directory?

Posted by timothy on from the all-in-the-same-gang dept.

trazom28 writes to seek answers to a problem faced by many businesses (and, as in this case, schools): "We are looking for a solution to a single sign on to coordinate Active Directory and Google. You can sync the passwords easily enough with Google Apps Password Sync, but ideally we would like the students and staff to be able to sign in once and be done. Additionally, the Google login requires the @domain.k12.wi.us so it would have to take the AD username, pass it along and tack on the domain to log into Google.

Has anyone seen any solution for this that actually works, or is this the Holy Grail of all IT? Please hold off on any Google haters, that's a different discussion for a different forum.

7 of 168 comments (clear)

  1. LDAP won't work? by drakaan · · Score: 4, Informative

    https://support.google.com/a/a...

    I googled it.

    --
    "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    1. Re:LDAP won't work? by laird · · Score: 3, Informative

      If you run AD, you should probably run ADFS. http://msdn.microsoft.com/en-u...

      It runs on top of AD, and provides standards-based SSO for users. It works nicely with Google Apps.

      It's a bit complex to set up, but there are articles like http://www.huggill.com/2012/01... . Basically, ADFS is a SAML Identity Provider and Google Apps is a SAML Service Provider. So when users go to log into Google using your domain, they are redirected to ADFS to log in, which validates them against AD, then redirects them back to Google. Then when they access any other service that you have SSO with, the user doesn't have to re-authenticate.

      You can do the same thing with Ping Federate. If nothing else, you can get quotes from both. But if you get educational pricing from MS, ADFS is likely cheaper. ADFS doesn't cost anything (other than paying for the servers and OS) - the expensive part is buying the AD CALs for everyone doing SSO, which you already have.

      --
      Enable 3D printed prosthetics!
  2. Re:What the hell by Anonymous Coward · · Score: 2, Informative

    It's not unhelpful to point out that some students may not be willing to create a Google account, so any process that requires such is non-viable as a widespread solution.

  3. Holy Grail not needed by jose.tudela · · Score: 5, Informative

    You can use Active Directory and/or OpenLDAP and then simpleSAMLphp and link to Google Apps.

    We do it this way:

    1) RCDevs WebADM LDAP Directory (or in your case Active Directory)

    2) simpleSAMLphp There's actually a good tutorial to integrate with Google Apps here: https://simplesamlphp.org/docs...

    3) Google apps confitured for SAML 2.0

    It took me about 15 minutes to set it up.

    Any question feel free to ask.

  4. Using SAML, you can tell Google you are anyone by bsquizzato · · Score: 3, Informative

    I see a lot of people here pointing you to articles on how to set up a SAML IdP. I mean -- that is a start -- but you may still be confused on how to solve your problem. If I understand it correctly -- you want your users to be able to sign in using "username", but have "username@domain.com" passed on to Google Apps, correct?

    First, if you don't know what "SAML", "IdP" or "SP" is, read this: https://developers.google.com/google-apps/sso/saml_reference_implementation

    Then the process, no matter what IDP, is going to be similar.
    1) Choose your SAML IDP (OpenAM? Ping? ADFS? Others?)
    2) Set it up to authenticate your users using AD based on their username -- in other words it needs to match usernames/passwords that your end users provide on the login page based on the "sAMAccountName" attribute in MS AD.
    3) You will need to exchange SAML metadata between Google Apps and your IdP.
    4) When you import the Google Apps metadata to your IdP and configure the SP for Google Apps, configure the IDP to tell Google Apps that your username is the "mail" attribute in the Name Identifer -- or, if your mail attribute in LDAP does not have the correct @domain.com you need, then you could use the Active Directory "Attribute Editor" and just assign some random attribute the proper "Google ID" for each user. Then pass this attribute along to Google as the "Name ID"

    The nice thing about ADFS is it is so closely tied with Active Directory, so step #2 kind of takes care of itself. A guide for integrating ADFS and Google Apps is here: http://www.huggill.com/2012/01/12/setting-up-google-apps-single-sign-on-sso-with-adfs-2-0-and-a-custom-sts-such-as-identityserver/

    When that author gets to the part on "Select Transform an Incoming Claim from the Claim rule template drop-down:", I'd probably do it a bit differently. I'd instead do this:
    * Select "Send LDAP Attributes as Claims"
    * Send the "mail" attribute as outgoing claim type "Name ID" (or whatever attribute you want to use in LDAP for your Google usernames)

  5. I've done this. by Havokmon · · Score: 3, Informative
    I was InfoSec at a Fortune 500 company that moved to Google Apps and the Security rep for the email migration. SSO and account verification was to accomplished via SAML - so we could restrict non-exempt employees and consultants, etc. Not having worked with it before, I setup SimpleSAMLphp on my Windows laptop using my personal domain on Google. It took me about 40 minutes to get my local AD credentials to auth to my domain on Google.

    They paid $1mil for 4 servers to do the same thing.

    --
    "I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
  6. Re:What the hell by Vokkyt · · Score: 4, Informative

    Well, GAFE accounts aren't normal google accounts. Function wise they're the same, but Google promotes that they are not put through the same advertising analytics that normal gmail accounts are.

    From the GAFE website:

    Google Apps is governed by a detailed Privacy Policy, which ensures we will not inappropriately share or use personal information placed in our systems. Google complies with applicable US privacy law, and the Google Apps Terms of Service can specifically detail our obligations and compliance with FERPA (Family Educational Rights and Privacy Act) regulations. Google is registered with the US-EU Safe Harbor agreement, which helps ensure that our data protection compliance meets European Union standards for educational institutions

    FERPA is the big stickler here, as google really couldn't offer the service without being FERPA compliant, and they couldn't run Google Business as usual and still be FERPA compliant.

    Now, as to whether you choose to believe their claims, that's another story, but you're approaching it with a lot of misinformation, it seems.