Google Apps and Active Directory integration - help before it drives me mad!

[cheredenine]

So we're generally fed up of Fronter and the lack of decent support and are looking at alternatives. A school i went on a little visit to recently is using Google Apps and are loving it. I thought we'd have a look to to see ifs for us. Part of the requirements for us is that it links to another system for user creation etc, so that we don't have another system to maintain in parallel.

 

So i found the Google Apps Directory Sync application and started filling in details. Didn't get very far as the ldap connection will not work. I've tried all manner of combinations of distinguished name for the server and login account, and have tried the normal AD port for communications and the Global Catalogue port while pointed at the relevant server, all to no avail. The specific error appears to be generated by the java library they're using to make the connection and complains about being unable to bind - this suggests the user details are at fault, but not sure what else to try that doesn't involve a hammer.

 

Any suggestions?

 

The specific error message is as follows:

 

Error: Connection failed

Exception: javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece

 

Further info: I did try using ADAM on another machine to supply a 'flattened' version with anonymous access enabled, but data extraction problems still abound, even if the connection initially worked...

[Davit2005]

Are you behing the counties Filter/Proxy by any chance. We had to use a 3G dongle at last place to powershell to Live@EDU.

[AngryTechnician]

It looks more like the connection to the domain controller is failing than the connection to Google, so I don't think a proxy is to blame. My settings are as follows for reference (anonymised, obviously), and in this example my domain is ANGRYTECH with the FQDN being angrytech.internal

 

Connection type: Standard LDAP

Host Name: mydc.angrytech.internal (just the plain hostname also works for me)

Port: 389

Base DN: OU=People,DC=angrytech,DC=internal (this connects to an OU I created called People in the root of the AD)

 

Authentication type: Simple

Authorized user: ANGRYTECH\gads (this is a standard user I set up just for GADS)

Password: blahblahblah

[CyberNerd]

I agree with angrytechnician that it looks like a problem connecting to the domain controller.

I would check that the server you are running ADSync on can access port 389 (or global cat) by running telnet against it. If it fails it's likely to be a firewall. Also check the AntiVirus isn't blocking comms which can happen sometimes.

[morganw]

Don't you have to allow unsigned LDAP requests for your DCs?

[AngryTechnician]

Don't you have to allow unsigned LDAP requests for your DCs?

 

I didn't have to change this setting, though I can't guarantee it wasn't set already from when we used to be CC3. How would I check?

[morganw]

See if you have a policy set for:

 

Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options / Domain controller: LDAP server signing requirements

 

I think that's the right one to look at anyway, it's been a while since I adjusted my own to allow Moodle authentication via LDAP.

[cheredenine]

It looks more like the connection to the domain controller is failing than the connection to Google, so I don't think a proxy is to blame. My settings are as follows for reference (anonymised, obviously), and in this example my domain is ANGRYTECH with the FQDN being angrytech.internal

 

Connection type: Standard LDAP

Host Name: mydc.angrytech.internal (just the plain hostname also works for me)

Port: 389

Base DN: OU=People,DC=angrytech,DC=internal (this connects to an OU I created called People in the root of the AD)

 

Authentication type: Simple

Authorized user: ANGRYTECH\gads (this is a standard user I set up just for GADS)

Password: blahblahblah

 

Angrytech is spot on in that the problem is the connection to the domain controller. Problem is, i tried the exact same format as he did to connect, only for me it is not working.

I have checked the relevant policies for the domain controller and unsigned requests are allowed

I have tweaked the Symantec Endpoint firewall rules to specifically allow LDAP connections. This firewall has been such little trouble i had forgotten it even existed.

I try Telnet to connect to the DC via port 389; initially received 'lost connection to host', but since tweaking Endpoint it now takes me to a blank command prompt screen when i run the command. Not sure if this indicates success or not..

 

But still, Google Apps Directory Sync wont connect to AD. Any further ideas?

[CyberNerd]

I try Telnet to connect to the DC via port 389; initially received 'lost connection to host', but since tweaking Endpoint it now takes me to a blank command prompt screen when i run the command. Not sure if this indicates success or not..

 

Yes this is a good start. A blank screen with flashing cursor means its connected on 389. are you still getting the same error message though?

[cheredenine]

Yes this is a good start. A blank screen with flashing cursor means its connected on 389. are you still getting the same error message though?

 

Yeah, same error message! Haven't tried again this morning - scheduled a server restart over night, just in case that trick works... Can't think what else could be the issue!

 

Edit: Restart has made no difference; just tried installing on another server using same config file, but same error appears!

Edited December 2, 2011 by cheredenine

[CyberNerd]

can you run wireshark on the dc and see if the request is getting through.

[Netman]

You could try using port 3268 (works for me) - Google says:

What port numbers should be used in Google Apps Directory Sync when connecting to Global Catalog server?

By default, Google Apps Directory Sync connects to an LDAP server with the standard LDAP port 389 to query users from a single domain/LDAP server.

If you need to query users over multiple domains/LDAP servers that have trust relationship, configure Google Apps Directory Sync to connect to a Global Catalog server with the standard Global Catalog server port 3268.

More here: Common Issues

[cheredenine]

The wireshark comment is interesting - have installed and tested and a connection is received, the data request is recieved, then the connection is closed. So there isn't a block, but still its not working. Not sure how to proceed - not sure if Wireshark shows me anything i can use to diagnose further now its shown the request is getting through...

 

Had already tried using the Global Catalogue port to the relevant server - no dice...

[CyberNerd]

The wireshark comment is interesting - have installed and tested and a connection is received, the data request is recieved, then the connection is closed. So there isn't a block, but still its not working. Not sure how to proceed - not sure if Wireshark shows me anything i can use to diagnose further now its shown the request is getting through...

 

So the request gets there, but active directory doesn't send a response, just closes the connection? sounds a bit odd. Does anything else on your network use LDAP successfully? I'm wondering if it is an active directory security setting? Does the account that you're binding with have read access (it should by default)

[wesleyw]

Isn't there a setting in the GPO I seem to remember for allowing LDAP access something to do with NT4 compatibility?

 

Wes

[cheredenine]

Sorry for resurrecting an old thread, but i'm back after a long hiatus to fighting this blooming thing again.

 

After fiddling with an LDAP browser i have come to the conclusion that i'm somehow using the incorrect credentials to connect to AD, or using the wrong format somehow, or there is a third possibility blocking access. Currious thing is that if i ask the LDAP browser to use the credentials of the current logged in user (a Domain Admin account) it works and shows all my OUs. If i enter the same account details manually (in format CN=name,OU=Admin staff,DC=domain etc) i get problems - it'll throw errors and wont display the OUs i expect, just the Domain and Forest DNS zones and the cn=configuration thingy.

 

Any words of wisdom?

[AngryTechnician]

When you enter the authentication credentials, the Authorized User field should be in the format DOMAIN\name, not CN=name,OU=etc,dc=DOMAIN. Only the Base DN field needs DN formatting.

 

At least, that's how mine is set, and it works for me.

[cheredenine]

Hmmm... I try the domain\user format on the LDAP browser and its no different. Really odd - as far as i'm aware i should be able to connect and see all my OUs with any authorised user account, but any details i submit only show me the basics as mentioned. There must be a glitch in my reasoning or in AD itself somewhere; as mentioned above the 'user logged in user details' works fine in the LDAP browser, but no submitted user details in any format works.

 

**EDIT - mind = blown. Just tried the domain\user format again and it works in the ldap browser. Wierd, considering i'm sure i've tried this combination before! Onwards with persuading the Google app to find my OUs...

Edited April 26, 2012 by cheredenine

[cheredenine]

Spoke to soon - not sure what happened yesterday as its back to not working today in the LDAP browser.

 

I had been reading an article about how MS browser tools can do a 'bind redirection' that third party software might not, which would explain why I'm having trouble...

Edited April 27, 2012 by cheredenine
wrong word used

[wesleyw]

Yes but it also allowed linux and unix systems to access LDAP in a simpler way as well.