Sorry. Don't know what else to check for. Mine is setup with format and settings mentioned and it works fine and I experienced the same issue as you in the beginning.
-john- On Mon, Sep 9, 2013 at 12:17 PM, Antman, Jason (CMG-Atlanta) < [email protected]> wrote: > eh. Tried that, no difference. > > Thanks for all the time though. > -Jason > > On 09/09/2013 03:00 PM, John Tran wrote: > > One other thing i forget to mention, in your OM LDAP configuration, you > have your domain setting as the netbios name (CMG) or the FQDN? it need to > be in FQDN of your AD. cmg.local or the like. > > -john- > > > On Mon, Sep 9, 2013 at 11:50 AM, Antman, Jason (CMG-Atlanta) < > [email protected]> wrote: > >> John, >> >> Thanks for the tip. Still no dice. Tried with both our usual admin bind >> user and my own. The relevant portion of the logs: >> DEBUG 09-09 14:48:28.904 o.a.o.l.LdapLoginManagement:390 [NioProcessor-2] >> - authenticating admin... >> DEBUG 09-09 14:48:28.904 o.a.o.l.LdapAuthBase:101 [NioProcessor-2] - >> authenticateUser >> DEBUG 09-09 14:48:28.904 o.a.o.l.LdapAuthBase:117 [NioProcessor-2] - >> >> Authentification to LDAP - Server start >> DEBUG 09-09 14:48:28.905 o.a.o.l.LdapAuthBase:151 [NioProcessor-2] - >> loginToLdapServer >> DEBUG 09-09 14:48:28.929 o.a.o.l.LdapLoginManagement:393 [NioProcessor-2] >> - Checking server type... >> DEBUG 09-09 14:48:28.929 o.a.o.l.LdapAuthBase:101 [NioProcessor-2] - >> authenticateUser >> DEBUG 09-09 14:48:28.929 o.a.o.l.LdapAuthBase:117 [NioProcessor-2] - >> >> Authentification to LDAP - Server start >> DEBUG 09-09 14:48:28.929 o.a.o.l.LdapAuthBase:151 [NioProcessor-2] - >> loginToLdapServer >> ERROR 09-09 14:48:28.941 o.a.o.l.LdapAuthBase:123 [NioProcessor-2] - >> >> Authentification on LDAP Server failed : [LDAP: error code 49 - 80090308: >> LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, >> vece] >> ERROR 09-09 14:48:28.945 o.a.o.l.LdapAuthBase:124 [NioProcessor-2] - >> [Authentification on LDAP Server failed] >> javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: >> LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, >> vece] >> (and then traceback) >> >> Implies to me that the admin is being authenticated properly, but it's >> the user that's failing. >> >> Just a thought looking at the >> loginUser: <md5sum> jantman >> line... is this making some assumption that my LDAP server is storing >> passwords with MD5, which I assume is NOT the case with AD? >> >> Thanks, >> Jason >> >> On 09/09/2013 02:37 PM, John Tran wrote: >> >> Jason - >> >> I ran into the same issue when I first set mine up. What I noticed that >> on the ldap_admin_dn, you have put cn=The_Actual_Display_Name" followed by >> the rest of the format. >> >> For example: >> not CN:authuser,OU:MYORG,DC:example,DC:int >> but >> CN:Auth User,OU:MYORG,DC:example,DC:int >> Don't use the account login name "authuser" in the Account tab in the >> account details but rather display name in the OU that contains the Display >> name for that login name. >> >> -john- >> >> >> >> >> >> On Mon, Sep 9, 2013 at 11:24 AM, Antman, Jason (CMG-Atlanta) < >> [email protected]> wrote: >> >>> John, >>> >>> Thanks for the quick reply. I tried updating ldap_admin_dn to actually >>> be a DN, as well as changing the field_user_principal and ldap_server_type. >>> No change at all. I then tried changing the admin_dn to the DN of my user >>> (with domain admin privs) and the password to my password (which doesn't >>> contain a #), no change. Tried changing ldap_search_base to the OU where >>> all of the accounts (well, most of them, including mine) are located, still >>> no change. >>> >>> Any other thoughts? Is there a way to enable a more-verbose logging for >>> this? >>> >>> Thanks, >>> Jason >>> >>> On 09/09/2013 01:54 PM, John Tran wrote: >>> >>> Jason - >>> >>> A couple of things is wrong in your ldap config. >>> ldap_admin_dn= (wrong format, it should be something like >>> CN:LDAP_account,OU:MYORG,DC:example,DC:int) >>> >>> ldap_search_base= (your setting should be ok, mine is narowed down to >>> the OU where the >>> user accounts are located) >>> >>> field_user_principal= (this should be "userPrincipalName") >>> >>> ldap_server_type= (this should be "AD") >>> >>> -john- >>> >>> >>> On Mon, Sep 9, 2013 at 10:40 AM, Antman, Jason (CMG-Atlanta) < >>> [email protected]> wrote: >>> >>>> Hello, >>>> >>>> I've just installed OpenMeetings 2.1.1 on a CentOS 6 host for testing. >>>> Everything seems to work fine with local auth, but then I attempted to >>>> enable LDAP authentication to an Active Directory backend. As far as I >>>> can tell, the bind is working, but I seem to be getting back invalid >>>> password errors. I have dozens of other applications authing against >>>> this same AD instance, and I copy/pasted the username and password, so I >>>> know all of that is right. I thought it may have something to do with >>>> the bind user having a "#" in the password, but that doesn't seem to be >>>> the case, since the bind looks to be successful. I've tried setting >>>> ldap_server_type to both "AD" and "OpenLDAP" (per some old mailing list >>>> threads) but nothing seems to change with that. >>>> >>>> Does anyone else have AD auth working right? >>>> >>>> I'm attaching (slightly anonymized versions of) my om_ldap.cfg and >>>> openmeetings.log (I was unable to find instructions for how to turn on >>>> debug logging for the current version; the only document that Google >>>> turned up was http://code.google.com/p/openmeetings/wiki/Logging which >>>> points to a file that doesn't exist). >>>> >>>> I've tried my plain username with both a domain prefix (domain\username) >>>> and without. With the domain prefix I get a "Username not found" error, >>>> and without the prefix I get "Invalid password" (confirmed by the >>>> AcceptSecurityContext error 525) >>>> This implies to me (am I wrong): >>>> 1) bind to AD is successful >>>> 2) without the domain prefix is the correct format >>>> 3) The account can at least be found >>>> >>>> Thanks in advance for any help, and many thanks for all the effort that >>>> went in to a project that might finally free me (a desktop Linux user) >>>> from incompatible or proprietary conference software. >>>> >>>> -Jason Antman >>>> >>> >>> >>> >>> -- >>> jt >>> ________________________________ >>> John Tran >>> Northern California, CA >>> [email protected] >>> ICQ IM: 27741710 >>> AOL IM: find1ngj0hn >>> Yahoo! IM: findingj0hn >>> MSN IM: [email protected] >>> >>> >>> >>> -- >>> >>> Jason Antman | Systems Engineer | [email protected] | p: >>> 678-645-4155 >>> >>> >> >> >> -- >> jt >> ________________________________ >> John Tran >> Northern California, CA >> [email protected] >> ICQ IM: 27741710 >> AOL IM: find1ngj0hn >> Yahoo! IM: findingj0hn >> MSN IM: [email protected] >> >> >> >> -- >> >> Jason Antman | Systems Engineer | [email protected] | p: >> 678-645-4155 >> >> > > > -- > jt > ________________________________ > John Tran > Northern California, CA > [email protected] > ICQ IM: 27741710 > AOL IM: find1ngj0hn > Yahoo! IM: findingj0hn > MSN IM: [email protected] > > > > -- > > Jason Antman | Systems Engineer | [email protected] | p: > 678-645-4155 > > -- jt ________________________________ John Tran Northern California, CA [email protected] ICQ IM: 27741710 AOL IM: find1ngj0hn Yahoo! IM: findingj0hn MSN IM: [email protected]
