Has anyone tried configuring LDAP auth in InForm OS 3.1.2 and been successful? I am trying to setup LDAP auth on a 7200 using the same configuration we have on our v400 running 3.1.1 and it's giving me fits. I keep getting this error on the 7200 when using checkpassword.
+ authorization denied: Operations error
I have verified that the configs are identical between the two systems using the showauthparam. Any suggestions?
LDAP Auth issue in 3.1.2 MU2
Re: LDAP Auth issue in 3.1.2 MU2
Ok, I figured this one out myself. If you change ldap-port to 3268 in OS 3.1.2 MU2 you can search the root of the domain but must select an OU if you use ldap-port 389. Behavior seems to have changed from OS 3.1.1 to 3.1.2 but that's what's working now.
Just thought I'd share.
Just thought I'd share.
- Richard Siemers
- Site Admin
- Posts: 1333
- Joined: Tue Aug 18, 2009 10:35 pm
- Location: Dallas, Texas
Re: LDAP Auth issue in 3.1.2 MU2
Thanks for sharing. We just added a new 7200 with 3.1.2 MU1 and the same old setup notes I made from 2.2.4 still work, so perhaps its a change in MU2.
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
Re: LDAP Auth issue in 3.1.2 MU2
I am struggling to get LDAP authentication set up on 3.1.2. MU2. I have followed some of the posts on this forums but still have issues.
The below is the output of what my settings are. I have an AD group (3parscripts) in the "something" OU and the user account is in the same OU
I have tried domain-name-prefix with InServDomain= and !InServDomain= and made sure the description contains InServDomain=
ldap-server 10.1.x.x
ldap-ssl 0
account-obj user
allow-ssh-key 0
account-name-attr sAMAccountName
sasl-mechanism GSSAPI
accounts-dn OU=something,OU=admins,DC=company,DC=com
memberof-attr memberOf
ldap-port 389
kerberos-realm company.com
edit-map CN=3parscripts,OU=something,OU=admins,DC=company,DC=com
domain-name-attr description
binding sasl
ldap-server-hn ldap.company.com
group-obj group
domain-name-prefix InServDomain=
Any help would be appreciated.
The below is the output of what my settings are. I have an AD group (3parscripts) in the "something" OU and the user account is in the same OU
I have tried domain-name-prefix with InServDomain= and !InServDomain= and made sure the description contains InServDomain=
ldap-server 10.1.x.x
ldap-ssl 0
account-obj user
allow-ssh-key 0
account-name-attr sAMAccountName
sasl-mechanism GSSAPI
accounts-dn OU=something,OU=admins,DC=company,DC=com
memberof-attr memberOf
ldap-port 389
kerberos-realm company.com
edit-map CN=3parscripts,OU=something,OU=admins,DC=company,DC=com
domain-name-attr description
binding sasl
ldap-server-hn ldap.company.com
group-obj group
domain-name-prefix InServDomain=
Any help would be appreciated.
- Richard Siemers
- Site Admin
- Posts: 1333
- Joined: Tue Aug 18, 2009 10:35 pm
- Location: Dallas, Texas
Re: LDAP Auth issue in 3.1.2 MU2
check your kerberos realm... it is case sensitive. Mine was all caps.
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
-
- Posts: 9
- Joined: Fri Feb 28, 2014 1:41 pm
- Location: Fort Worth, TX
Re: LDAP Auth issue in 3.1.2 MU2
We ran into the same issue with the KERBEROS realm, they are most definitely case sensitive.
Nathan Bell
Solution Architect Principal
Dyncorp International
Solution Architect Principal
Dyncorp International
Re: LDAP Auth issue in 3.1.2 MU2
Go it ti work with AD without all th Kerberos realm stuff by using simple mode.
I substituted our data with generic names, but it was as simple as the following steps to get AD authentication working to provide edit permissions to an AD account in a specific OU under another OU.
setauthparam -f ldap-server 192.168.0.1
setauthparam -f ldap-server-hn servername.aaa.com
setauthparam -f binding simple
setauthparam -f user-attr DOMAINNAME\\
setauthparam -f accounts-dn OU=yyy,OU=zzz,DC=aaa,DC=com
setauthparam -f account-obj user
setauthparam -f account-name-attr SAMAccountName
setauthparam -f memberof-attr memberOf
setauthparam edit-map CN=xxx,OU=yyy,OU=zzz,DC=aaa,DC=com
I substituted our data with generic names, but it was as simple as the following steps to get AD authentication working to provide edit permissions to an AD account in a specific OU under another OU.
setauthparam -f ldap-server 192.168.0.1
setauthparam -f ldap-server-hn servername.aaa.com
setauthparam -f binding simple
setauthparam -f user-attr DOMAINNAME\\
setauthparam -f accounts-dn OU=yyy,OU=zzz,DC=aaa,DC=com
setauthparam -f account-obj user
setauthparam -f account-name-attr SAMAccountName
setauthparam -f memberof-attr memberOf
setauthparam edit-map CN=xxx,OU=yyy,OU=zzz,DC=aaa,DC=com