Hi, I´m with some troubles to do authentication in AD trough of Openldap.
Somebody managed to authenticate with AD password in Openldap Server?
I´m trying everything but don´t auth. I see all users but the password don´t pass.
My slapd.conf like this :
# include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema
#allow bind_v2
loglevel 256 #referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules: modulepath /usr/lib/openldap #moduleload back_bdb moduleload accesslog.la moduleload auditlog.la moduleload ppolicy.la moduleload rwm.la moduleload back_ldap
TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#######################################################################
database ldap suffix "dc=foobar" rootdn "cn=admin,dc=foobar" ################################### rootpw {SSHA}wXmTs2ANS4XwqqnzEVIqmc+i6VCUiD7I
database ldap suffix dc=foobar,dc=com #subordinate rebind-as-user uri ldaps://srv-2003.foobar.com idassert-bind bindmethod=simple binddn="cn=vmail,cn=users,dc=foobar,dc=com" credentials=abc@123 mode=none flags=non-prescriptive
idassert-authzFrom "dn.regex:.*" #idassert-authzFrom "dn.exact:cn=admin,dc=foobar" # chase-referrals yes
require authc ############################# ###########password-hash {CLEARTEXT} TLSCipherSuite HiGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 TLSVerifyClient allow sasl-host localhost sasl-secprops none
######################################################################### database config # all others attributes are readable to everybody
access to * by * read
lastmod off
overlay rwm rwm-suffixmassage dc=foobar,dc=com #rwm-normalize-mapped-attrs rwm-map attribute uid sAMAccountName rwm-map attribute cn name #rwm-map attribute mail userPrincipalName rwm-map objectclass account
What is wrong?
Please help me.
Thanks.
You are trying to authenticate through the credentials stored in your active directory servers, not the passwords stored in LDAP, correct? If that is the case, then the easiest means to accomplish that are to use SASL for authentication.
On Tue, Nov 19, 2013 at 12:59 PM, wrm@cdtn.br wrote:
Hi, I´m with some troubles to do authentication in AD trough of Openldap.
Somebody managed to authenticate with AD password in Openldap Server?
I´m trying everything but don´t auth. I see all users but the password don´t pass.
My slapd.conf like this :
# include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema
#allow bind_v2
loglevel 256 #referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules: modulepath /usr/lib/openldap #moduleload back_bdb moduleload accesslog.la moduleload auditlog.la moduleload ppolicy.la moduleload rwm.la moduleload back_ldap
TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#######################################################################
database ldap suffix "dc=foobar" rootdn "cn=admin,dc=foobar" ################################### rootpw {SSHA}wXmTs2ANS4XwqqnzEVIqmc+i6VCUiD7I
database ldap suffix dc=foobar,dc=com #subordinate rebind-as-user uri ldaps://srv-2003.foobar.com idassert-bind bindmethod=simple binddn="cn=vmail,cn=users,dc=foobar,dc=com" credentials=abc@123 mode=none flags=non-prescriptive
idassert-authzFrom "dn.regex:.*" #idassert-authzFrom "dn.exact:cn=admin,dc=foobar" # chase-referrals yes
require authc ############################# ###########password-hash {CLEARTEXT} TLSCipherSuite HiGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 TLSVerifyClient allow sasl-host localhost sasl-secprops none
######################################################################### database config # all others attributes are readable to everybody
access to * by * read
lastmod off
overlay rwm rwm-suffixmassage dc=foobar,dc=com #rwm-normalize-mapped-attrs rwm-map attribute uid sAMAccountName rwm-map attribute cn name #rwm-map attribute mail userPrincipalName rwm-map objectclass account
What is wrong?
Please help me.
Thanks.
2013/11/19 Jason Brandt jbrandt@fsmail.bradley.edu:
You are trying to authenticate through the credentials stored in your active directory servers, not the passwords stored in LDAP, correct? If that is the case, then the easiest means to accomplish that are to use SASL for authentication.
You can check this how-to: http://ltb-project.org/wiki/documentation/general/sasl_delegation
Clément.
Clément OUDOT wrote:
2013/11/19 Jason Brandt jbrandt@fsmail.bradley.edu:
You are trying to authenticate through the credentials stored in your active directory servers, not the passwords stored in LDAP, correct? If that is the case, then the easiest means to accomplish that are to use SASL for authentication.
Or he could just read up on slapo-pbind.
You can check this how-to: http://ltb-project.org/wiki/documentation/general/sasl_delegation
Clément.
2013/11/20 Howard Chu hyc@symas.com:
Clément OUDOT wrote:
2013/11/19 Jason Brandt jbrandt@fsmail.bradley.edu:
You are trying to authenticate through the credentials stored in your active directory servers, not the passwords stored in LDAP, correct? If that is the case, then the easiest means to accomplish that are to use SASL for authentication.
Or he could just read up on slapo-pbind.
Seems pbind overlay do not allow to have a different DN between OpenLDAP and AD, am I right?
And also, with SASL delegation, you are able to choose which accounts will use SASL pass trough, and which account will have their password stored locally. Is it possible with pbind?
Clément.
Thank you.
Yes, the credentials are stored in AD.
I saw this documentation, http://ltb-project.org/wiki/documentation/general/sasl_delegation
Helped me very much, but I think there are some wrong in my saslauth.conf, because when I put the AD server and ldap_filter = (sAMAccountName=%u is Ok Success SASL, " but when I put my localhost like this:
ldap_servers: ldaps://127.0.0.1 #or ldap://localhost #ldap_servers: ldaps://1.1.2.1 ldap_version: 3 ldap_auth_method: bind ldap_search_base: cn=users,dc=foobar,dc=br #ldap_filter: (sAMAccountname=%u) #ldap_filter: (userPrincipalName=%u) ldap_filter: uid=%u ldap_bind_dn: cn=vmail,cn=users,dc=foobar,dc=br #or cn=admin,dc=foobar ldap_password: abc@123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_timeout: 10
testsaslauthd -u usertst -p password
NO "authentication failed"
See the log:
Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 ACCEPT from IP=127.0.0.1:50194 (IP=0.0.0.0:636) Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 TLS established tls_ssf=256 ssf=256 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" method=128 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" mech=SIMPLE ssf=0 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 RESULT tag=97 err=0 text= Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH base="cn=users,dc=foobar,dc=br" scope=2 deref=0 filter="(uid=usertst)" Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH attr=dn Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
What can I do to fix this?
Willy R.M
Clément OUDOT wrote:
2013/11/19 Jason Brandt jbrandt@fsmail.bradley.edu:
You are trying to authenticate through the credentials stored in your active directory servers, not the passwords stored in LDAP, correct? If that is the case, then the easiest means to accomplish that are to use SASL for authentication.
Or he could just read up on slapo-pbind.
You can check this how-to: http://ltb-project.org/wiki/documentation/general/sasl_delegation
Clément.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
2013/11/20 wrm@cdtn.br:
Thank you.
Yes, the credentials are stored in AD.
I saw this documentation, http://ltb-project.org/wiki/documentation/general/sasl_delegation
Helped me very much, but I think there are some wrong in my saslauth.conf, because when I put the AD server and ldap_filter = (sAMAccountName=%u is Ok Success SASL, " but when I put my localhost like this:
ldap_servers: ldaps://127.0.0.1 #or ldap://localhost #ldap_servers: ldaps://1.1.2.1 ldap_version: 3 ldap_auth_method: bind ldap_search_base: cn=users,dc=foobar,dc=br #ldap_filter: (sAMAccountname=%u) #ldap_filter: (userPrincipalName=%u) ldap_filter: uid=%u ldap_bind_dn: cn=vmail,cn=users,dc=foobar,dc=br #or cn=admin,dc=foobar ldap_password: abc@123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_timeout: 10
testsaslauthd -u usertst -p password
NO "authentication failed"
See the log:
Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 ACCEPT from IP=127.0.0.1:50194 (IP=0.0.0.0:636) Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 TLS established tls_ssf=256 ssf=256 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" method=128 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" mech=SIMPLE ssf=0 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 RESULT tag=97 err=0 text= Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH base="cn=users,dc=foobar,dc=br" scope=2 deref=0 filter="(uid=usertst)" Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH attr=dn Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
What can I do to fix this?
The log says that the entry is not found (nentries=0) either because it does not exist, either because you can't read it (ACL).
But what are you using localhost behind your SASL pass trough? Seems like you are doing a loop on your LDAP server.
Clément.
I can get you my SASL config from my test environment when I get to the office. One thing to keep in mind, is that you MUST do an authenticated bind to AD, you cannot do anonymous bind, so you have to have a service account setup to allow SASL to authenticate to AD. It can be the most basic user account, just has to be able to log into AD.
On Wed, Nov 20, 2013 at 6:26 AM, Clément OUDOT clem.oudot@gmail.com wrote:
2013/11/20 wrm@cdtn.br:
Thank you.
Yes, the credentials are stored in AD.
I saw this documentation, http://ltb-project.org/wiki/documentation/general/sasl_delegation
Helped me very much, but I think there are some wrong in my
saslauth.conf,
because when I put the AD server and ldap_filter = (sAMAccountName=%u is Ok Success SASL, " but when I put my localhost like this:
ldap_servers: ldaps://127.0.0.1 #or ldap://localhost #ldap_servers: ldaps://1.1.2.1 ldap_version: 3 ldap_auth_method: bind ldap_search_base: cn=users,dc=foobar,dc=br #ldap_filter: (sAMAccountname=%u) #ldap_filter: (userPrincipalName=%u) ldap_filter: uid=%u ldap_bind_dn: cn=vmail,cn=users,dc=foobar,dc=br #or
cn=admin,dc=foobar
ldap_password: abc@123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_timeout: 10
testsaslauthd -u usertst -p password
NO "authentication failed"
See the log:
Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 ACCEPT from IP=127.0.0.1:50194 (IP=0.0.0.0:636) Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 TLS established tls_ssf=256 ssf=256 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" method=128 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" mech=SIMPLE ssf=0 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 RESULT tag=97 err=0
text=
Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH base="cn=users,dc=foobar,dc=br" scope=2 deref=0 filter="(uid=usertst)" Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH attr=dn Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
What can I do to fix this?
The log says that the entry is not found (nentries=0) either because it does not exist, either because you can't read it (ACL).
But what are you using localhost behind your SASL pass trough? Seems like you are doing a loop on your LDAP server.
Clément.
This is all that's contained in my saslauthd.conf:
ldap_servers: ldaps://server2 ldaps://server1
ldap_search_base: OU=<usersOU>,DC=foo,DC=bar ldap_filter: sAMAccountName=%u ldap_bind_dn: cn=saslauthd,cn=users,dc=foo,dc=bar ldap_password: <password>
The obvious thing that jumps out at me is that you're pointing to ldap_servers: localhost, instead of your AD servers.
On Wed, Nov 20, 2013 at 7:37 AM, Jason Brandt jbrandt@fsmail.bradley.eduwrote:
I can get you my SASL config from my test environment when I get to the office. One thing to keep in mind, is that you MUST do an authenticated bind to AD, you cannot do anonymous bind, so you have to have a service account setup to allow SASL to authenticate to AD. It can be the most basic user account, just has to be able to log into AD.
On Wed, Nov 20, 2013 at 6:26 AM, Clément OUDOT clem.oudot@gmail.comwrote:
2013/11/20 wrm@cdtn.br:
Thank you.
Yes, the credentials are stored in AD.
I saw this documentation, http://ltb-project.org/wiki/documentation/general/sasl_delegation
Helped me very much, but I think there are some wrong in my
saslauth.conf,
because when I put the AD server and ldap_filter = (sAMAccountName=%u is Ok Success SASL, " but when I put my localhost like this:
ldap_servers: ldaps://127.0.0.1 #or ldap://localhost #ldap_servers: ldaps://1.1.2.1 ldap_version: 3 ldap_auth_method: bind ldap_search_base: cn=users,dc=foobar,dc=br #ldap_filter: (sAMAccountname=%u) #ldap_filter: (userPrincipalName=%u) ldap_filter: uid=%u ldap_bind_dn: cn=vmail,cn=users,dc=foobar,dc=br #or
cn=admin,dc=foobar
ldap_password: abc@123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_timeout: 10
testsaslauthd -u usertst -p password
NO "authentication failed"
See the log:
Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 ACCEPT from IP=127.0.0.1:50194 (IP=0.0.0.0:636) Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 TLS established tls_ssf=256 ssf=256 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" method=128 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" mech=SIMPLE ssf=0 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 RESULT tag=97 err=0
text=
Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH base="cn=users,dc=foobar,dc=br" scope=2 deref=0 filter="(uid=usertst)" Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH attr=dn Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
What can I do to fix this?
The log says that the entry is not found (nentries=0) either because it does not exist, either because you can't read it (ACL).
But what are you using localhost behind your SASL pass trough? Seems like you are doing a loop on your LDAP server.
Clément.
-- Jason K. Brandt Systems Administrator Bradley University (309) 677-2958
Em 20/11/2013 10:26, Clément OUDOT escreveu:
2013/11/20 wrm@cdtn.br:
Thank you.
Yes, the credentials are stored in AD.
I saw this documentation, http://ltb-project.org/wiki/documentation/general/sasl_delegation
Helped me very much, but I think there are some wrong in my saslauth.conf, because when I put the AD server and ldap_filter = (sAMAccountName=%u is Ok Success SASL, " but when I put my localhost like this:
ldap_servers: ldaps://127.0.0.1 #or ldap://localhost #ldap_servers: ldaps://1.1.2.1 ldap_version: 3 ldap_auth_method: bind ldap_search_base: cn=users,dc=foobar,dc=br #ldap_filter: (sAMAccountname=%u) #ldap_filter: (userPrincipalName=%u) ldap_filter: uid=%u ldap_bind_dn: cn=vmail,cn=users,dc=foobar,dc=br #or cn=admin,dc=foobar ldap_password: abc@123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_timeout: 10
testsaslauthd -u usertst -p password
NO "authentication failed"
See the log:
Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 ACCEPT from IP=127.0.0.1:50194 (IP=0.0.0.0:636) Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 TLS established tls_ssf=256 ssf=256 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" method=128 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" mech=SIMPLE ssf=0 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 RESULT tag=97 err=0 text= Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH base="cn=users,dc=foobar,dc=br" scope=2 deref=0 filter="(uid=usertst)" Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH attr=dn Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
What can I do to fix this?
The log says that the entry is not found (nentries=0) either because it does not exist, either because you can't read it (ACL).
But what are you using localhost behind your SASL pass trough? Seems like you are doing a loop on your LDAP server.
Clément.
That is a problem, because don´t found the base but when I´m using ldapsearch my search is acepted, very strange.
how this example: ldapsearch -x -H ldaps://localhost -b dc=foobar,dc=com -D cn=usertst,cn=users,dc=foobar,dc=com -w password
I see all objects in database, when I do this command.
If you had another idea please tell me, I just was seeing that link in the ltb-project.org. where tell me to use in localhost SASL.
Well, if you're going to use SASL, then you need to configure your saslauth.conf like my example, making sure your ldap servers point to your Active Directory servers. Otherwise if you're going to use some method besides SASL, then I won't be much help.
On Wed, Nov 20, 2013 at 10:55 AM, Willy Ramos wrm@cdtn.br wrote:
Em 20/11/2013 10:26, Clément OUDOT escreveu:
2013/11/20 wrm@cdtn.br:
Thank you.
Yes, the credentials are stored in AD.
I saw this documentation, http://ltb-project.org/wiki/documentation/general/sasl_delegation
Helped me very much, but I think there are some wrong in my saslauth.conf, because when I put the AD server and ldap_filter = (sAMAccountName=%u is Ok Success SASL, " but when I put my localhost like this:
ldap_servers: ldaps://127.0.0.1 #or ldap://localhost #ldap_servers: ldaps://1.1.2.1 ldap_version: 3 ldap_auth_method: bind ldap_search_base: cn=users,dc=foobar,dc=br #ldap_filter: (sAMAccountname=%u) #ldap_filter: (userPrincipalName=%u) ldap_filter: uid=%u ldap_bind_dn: cn=vmail,cn=users,dc=foobar,dc=br #or cn=admin,dc=foobar ldap_password: abc@123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_timeout: 10
testsaslauthd -u usertst -p password
NO "authentication failed"
See the log:
Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 ACCEPT from IP=127.0.0.1:50194 (IP=0.0.0.0:636) Nov 20 09:13:23 mail slapd[12776]: conn=1139 fd=18 TLS established tls_ssf=256 ssf=256 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" method=128 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 BIND dn="cn=vmail,cn=users,dc=foobar,dc=br" mech=SIMPLE ssf=0 Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=0 RESULT tag=97 err=0 text= Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH base="cn=users,dc=foobar,dc=br" scope=2 deref=0 filter="(uid=usertst)" Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SRCH attr=dn Nov 20 09:13:23 mail slapd[12776]: conn=1139 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
What can I do to fix this?
The log says that the entry is not found (nentries=0) either because
it does not exist, either because you can't read it (ACL).
But what are you using localhost behind your SASL pass trough? Seems like you are doing a loop on your LDAP server.
Clément.
That is a problem, because don´t found the base but when I´m using
ldapsearch my search is acepted, very strange.
how this example: ldapsearch -x -H ldaps://localhost -b dc=foobar,dc=com -D cn=usertst,cn=users,dc=foobar,dc=com -w password
I see all objects in database, when I do this command.
If you had another idea please tell me, I just was seeing that link in the ltb-project.org. where tell me to use in localhost SASL.
-- Att.
Willy R. M CDTN/System Software 31-3069-3303
On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote:
Subject: Re: Openldap for proxy AD
Have you tried following the examples in the Admin Guide?
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
There is a detailed setup and diagnosic guide there which should help you to isolate the problem.
Andrew
Em 22/11/2013 09:21, Andrew Findlay escreveu:
On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote:
Subject: Re: Openldap for proxy AD
Have you tried following the examples in the Admin Guide?
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
There is a detailed setup and diagnosic guide there which should help you to isolate the problem.
Andrew
Thanks Andrew,
I was testing based in this Admin Guide.
When I Check that the user can bind to AD:
ldapsearch -x -H ldap://dc1.example.com/ \ -D cn=user,cn=Users,DC=ad,DC=example,DC=com \ -w userpassword \ -b cn=user,cn=Users,DC=ad,DC=example,DC=com \ Or with -s base \ "(objectclass=*)" Or
testsaslauthd -u user -p userpassword
It´s works.
I was reading about and Seems don´t find the schemas of objectclass or userPassword attribute;
But I could not resolve yet.
See the logs
Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from IP=127.0.0.1:51698 (IP=0.0.0.0:636) Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established tls_ssf=256 ssf=256 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1 text=TLS already started Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed
Thanks.
Hi,
since it is working for a lot of people (including some of our customers) it seems that you are doing something wrong.
What about the contents of your entries: Are you sure that you have the attribute userPassword with the value
{SASL}<username>@<AD-realm>
set in all entries that are to bind via AD?
Cheers,
Peter
Am 22.11.2013 15:05, schrieb Willy Ramos:
Em 22/11/2013 09:21, Andrew Findlay escreveu:
On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote:
Subject: Re: Openldap for proxy AD
Have you tried following the examples in the Admin Guide?
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
There is a detailed setup and diagnosic guide there which should help you to isolate the problem.
Andrew
Thanks Andrew,
I was testing based in this Admin Guide.
When I Check that the user can bind to AD:
ldapsearch -x -H ldap://dc1.example.com/ \ -D cn=user,cn=Users,DC=ad,DC=example,DC=com \ -w userpassword \ -b cn=user,cn=Users,DC=ad,DC=example,DC=com \ Or with -s base \ "(objectclass=*)" Or
testsaslauthd -u user -p userpassword
It´s works.
I was reading about and Seems don´t find the schemas of objectclass or userPassword attribute;
But I could not resolve yet.
See the logs
Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from IP=127.0.0.1:51698 (IP=0.0.0.0:636) Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established tls_ssf=256 ssf=256 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1 text=TLS already started Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed
Thanks.
Hi,
Yes, there are some entries with the attribute userPassword like this value.
But don´t found the entries, when I put the password.
Thanks.
Em 25/11/2013 12:54, Peter Gietz escreveu:
Hi,
since it is working for a lot of people (including some of our customers) it seems that you are doing something wrong.
What about the contents of your entries: Are you sure that you have the attribute userPassword with the value
{SASL}<username>@<AD-realm>
set in all entries that are to bind via AD?
Cheers,
Peter
Am 22.11.2013 15:05, schrieb Willy Ramos:
Em 22/11/2013 09:21, Andrew Findlay escreveu:
On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote:
Subject: Re: Openldap for proxy AD
Have you tried following the examples in the Admin Guide?
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
There is a detailed setup and diagnosic guide there which should help you to isolate the problem.
Andrew
Thanks Andrew,
I was testing based in this Admin Guide.
When I Check that the user can bind to AD:
ldapsearch -x -Hldap://dc1.example.com/ \ -D cn=user,cn=Users,DC=ad,DC=example,DC=com \ -w userpassword \ -b cn=user,cn=Users,DC=ad,DC=example,DC=com \ Or with -s base \ "(objectclass=*)" Or
testsaslauthd -u user -p userpassword
It´s works.
I was reading about and Seems don´t find the schemas of objectclass or userPassword attribute;
But I could not resolve yet.
See the logs
Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from IP=127.0.0.1:51698 (IP=0.0.0.0:636) Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established tls_ssf=256 ssf=256 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1 text=TLS already started Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed
Thanks.
openldap-technical@openldap.org
-
Andrew Findlay -
Clément OUDOT -
Howard Chu -
Jason Brandt -
Peter Gietz -
Willy Ramos -
wrm＠cdtn.br