openldap default username/password?
by Kwasi Gyasi - Agyei
Hi,
I'm trying to configure openldap using slapd.d style configuration, however
command:
#ldapadd -vxh localhost -D cn=admin,cn=config -w "" -f
/usr/local/conf/shared/openldap/init-config.ldif
fails with error
ldap_initialize( ldap://localhost )
ldap_bind: Server is unwilling to perform (53)
additional info: unauthenticated bind (DN with no password) disallowed
#ldapadd -vxh localhost -f /usr/local/conf/shared/openldap/init-config.ldif
fails with error
ldap_initialize( ldap://localhost )
add objectClass:
olcGlobal
add olcLogFile:
/var/log/openldap/openldap.log
add olcLogLevel:
-1
adding new entry "cn=config"
ldap_add: Strong(er) authentication required (8)
additional info: modifications require authentication
any ideas?
--
Multimedia and Communication | Property | Entertainment
Kwasi Owusu Gyasi - Agyei
*cell* (+27) (0) 76 466 4488
*website *www.4things.co.za
*email *kwasi.gyasiagyei(a)4things.co.za
*skype *kwasi.gyasiagyei
*role* Developer.Designer.Software Architect
11 years, 7 months
Issues in implementing SASL
by Gaurav Gugnani
Hello All,
I'm trying to configure SASL on openldap and did following steps:
1> Modify the password of the user:
saslpasswd2 -c -u <realm> <username>
2> Then i modify slapd.conf:
sasl-regexp uid=(.*),cn=<realm>,cn=DIGEST-MD5,cn=auth
uid=$1,ou=System,o=<realm>
3> After this i try to do ldapsearch and it gave me an error:
ldap_bind: Server is unwilling to perform (53)
additional info: unauthenticated bind (DN with no password)
disallowed
Somewhere i read that we have to provide SASL information in slapd.conf
however when i write below mentioned content - then ldap doesn't re-start.
dn:uid=<username>,ou=System,o=<realm>
bindmethod=sasl
saslmech=DIGEST-MD5
credentials=<password>
realm=<realm>
Please help in resolving SASL mechanism to be used.
Thanks and Regards,
Gaurav Gugnani
11 years, 7 months
OpenLDAP with BackSQL and Postgres. Upper on bigint?
by Manny
Hi there.
I'm sorry for the SPAM. I'm posting this again as apparently I sent it
to the wrong mailing
list before. I then opened a bug report (ITS#7130) and was hinted that
I should write to this mailing list instead, which I did, but it
didn't go through (not in the archive) so I subscribed and now try it
again. Really sorry if you got my mail many times :(
I'm using the latest stable release of openldap, with back-sql and
postgresql as a backend.
I have an sssd which uses this openldap server for ID providing and
authentication.
A recent update in this sssd changed the filter used to retrieve
groupids of users, which surfaced what seems to be a bug in backsql.
>From my investigation it seems to me that when constructing the search
query, openldap tries to use the UPPER function on every criteria in
the WHERE clause, no matter which type it is. This causes an error in
postgresql, as the gidNumber that is supposed to be filtered is of
type "bigint".
I could simply remove "upper_func" from my slapd.conf, but I need it
for other queries. Changing the field gidNumber in the database to
text would also be a workaround, but I'd rather prefer this fixed in
backsql.
Anyways, here is the important part of my slapd.conf:
#-----------------------------------------------
database sql
suffix "dc=mydomain,dc=at"
rootdn "cn=Manager,dc=mydomain,dc=at"
rootpw mysecret
dbname mydbname
dbuser mydbuser
dbpasswd myuserpw
subtree_cond "UPPER(ldap_entries.dn) LIKE UPPER('%'||?)"
insentry_stmt "insert into ldap_entries
(id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from
ldap_entries),?,?,?,?)"
upper_func "upper"
upper_needs_cast "yes"
strcast_func "text"
concat_pattern "?||?"
has_ldapinfo_dn_ru no
sizelimit -1
#-----------------------------------------------
The error can be reproduced in my case when running this command:
#-----------------------------------------------
ldapsearch -H ldaps://127.0.0.1/ -b
ou=groups,ou=myserver,dc=mydomain,dc=at -D
"uid=myuser,ou=users,ou=myserver,dc=mydomain,DC=at" '(gidNumber=512)'
-W
#-----------------------------------------------
Which results in this output:
#-----------------------------------------------
# extended LDIF
#
# LDAPv3
# base <ou=groups,ou=myserver,dc=mydomain,dc=at> with scope subtree
# filter: (gidNumber=512)
# requesting: ALL
#
# search result
search: 2
result: 80 Other (e.g., implementation specific) error
#-----------------------------------------------
Here is the interesting part of the level 255 log output:
#-----------------------------------------------
<==backsql_oc_get_candidates(): 0
==>backsql_oc_get_candidates(): oc="sambaDomain"
==>backsql_srch_query()
==>backsql_process_filter()
<==backsql_process_filter() succeeded
<==backsql_srch_query() returns SELECT DISTINCT
ldap_entries.id,samba_domain_ldap.id,text('sambaDomain') AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,samba_domain_ldap
WHERE samba_domain_ldap.id=ldap_entries.keyval AND
ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE
UPPER('%'||?) AND 7=7
Constructed query: SELECT DISTINCT
ldap_entries.id,samba_domain_ldap.id,text('sambaDomain') AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,samba_domain_ldap
WHERE samba_domain_ldap.id=ldap_entries.keyval AND
ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE
UPPER('%'||?) AND 7=7
id: '6'
(sub)dn: "%OU=GROUPS,OU=MYSERVER,DC=MYDOMAIN,DC=AT"
<==backsql_oc_get_candidates(): 0
==>backsql_oc_get_candidates(): oc="inetOrgPerson"
==>backsql_srch_query()
==>backsql_process_filter()
==>backsql_process_filter_attr(gidNumber)
<==backsql_process_filter_attr(gidNumber)
<==backsql_process_filter() succeeded
<==backsql_srch_query() returns SELECT DISTINCT
ldap_entries.id,OS_USER.id,text('inetOrgPerson') AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,OS_USER WHERE
OS_USER.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND
UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND
(upper(OS_USER.gidnumber)='512')
Constructed query: SELECT DISTINCT
ldap_entries.id,OS_USER.id,text('inetOrgPerson') AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,OS_USER WHERE
OS_USER.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND
UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND
(upper(OS_USER.gidnumber)='512')
id: '8'
(sub)dn: "%OU=GROUPS,OU=MYSERVER,DC=MYDOMAIN,DC=AT"
backsql_oc_get_candidates(): error executing query
Return code: -1
nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR:
function upper(bigint) does not exist at character 288;#012Error while
executing the query"
#-----------------------------------------------
I got a hint that I might be able to configure this in
ldap_attr_mappings, but as I can find no documentation on what the
columns in this table mean, it's hard for me to figure out what to do.
The only thing that I can tell is that I can not see the word UPPER
anywhere in the sel_expr field (or any other field for that matter).
Thanks a lot in advance for your help.
11 years, 7 months
Re: Assertion failure -- using relay backend and translucent overlay
by Mattias Andersson
On Sun, 29 Jan 2012 17:10:00 +0100, Hallvard B Furuseth
<h.b.furuseth(a)usit.uio.no> wrote:
>>> ldapsearch -x -h localhost -b "dc=example,dc=com" -s base
>>> "(objectClass=*)" 1.1
>> (...)
>> Ok, here's the debug output from the above ldapsearch query:
>> (...)
>> conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=2 deref=0
>> filter="(objectClass=*)"
>> conn=1000 op=1 SRCH attr=1.1
>
> Strange. Did you include -s base? scope=2 in the log is subtree.
It automatically changed to scope=2 when I appended 1.1.
> Anyway, I suggest you answer in the ITS instead.
> A crash is certainly a bug which needs fixing.
Ok, I'll post a bug report. Btw, I'm using slapd 2.4.25 (Nov 14 2011
21:34:11).
Mattias
11 years, 7 months
Assertion failure -- using relay backend and translucent overlay
by Mattias Andersson
Hi,
I have configured a proxy server with its own local database that is used
both to override existing attributes of a remote database and to add its
own entries to the directory.
I have configured the local database as subordinate and I have configured
a relay database that is also pointing to the local database, but it is
using the translucent overlay to connect to the remote ldap directory.
My slapd.conf configuration:
backend hdb
backend ldap
database hdb
directory /var/lib/ldap
suffix "dc=foo,dc=example,dc=com"
rootdn "cn=admin,dc=foo,dc=example,dc=com"
rootpw secret
index objectClass eq
subordinate
database relay
suffix "dc=example,dc=com"
overlay rwm
rwm-suffixmassage "dc=foo,dc=example,dc=com"
overlay translucent
uri ldap://ldap.example.com
translucent_bind_local
This configuration actually does exactly what I have been trying to
achieve. I can override user attributes and at the same time I can add
additional group entries without having root access to the remote server.
I have tested it with the ldap nss service in linux and it works without
errors. The updated user accounts are correctly retrieved and the new
groups are added transparently. If I use ldapsearch, it will search both
the local and the remote server.
The problem that I've experienced is that when I'm using a different ldap
client, such as Softerra LDAP Administrator, then the daemon crashes when
a search query is performed:
slapd starting
conn=1000 fd=11 ACCEPT from IP=X.X.X.X:61230 (IP=0.0.0.0:389)
conn=1000 op=0 BIND dn="" method=128
conn=1000 op=0 RESULT tag=97 err=0 text=
conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0
filter="(objectClass=*)"
conn=1000 op=1 SRCH attr=1.1
conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self.
slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236:
attr_dup2: Assertion `j < i' failed.
Aborted
The message that "back-relay would call itself" is also logged when using
ldapsearch, but ldapsearch does not cause an assertion failure:
slapd starting
conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36760 (IP=0.0.0.0:389)
conn=1000 op=0 BIND dn="" method=128
conn=1000 op=0 RESULT tag=97 err=0 text=
conn=1000 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self.
PROXIED attributeDescription "ORCLNETDESCSTRING" inserted.
conn=1000 op=1 SEARCH RESULT tag=101 err=4 nentries=300 text=
conn=1000 op=2 UNBIND
conn=1000 fd=11 closed
I'm happy with the proxy functionality that I've managed to configure
(which is working), but it's definitely a security vulnerability when
simply using a different LDAP client causes the server to crash.
Is there any way I could avoid the assertion failure? Should I post a bug
report?
TIA,
Mattias
11 years, 7 months
syncrepl failing with ldap_start_tls failed (-11)
by Iain Georgeson
Hello,
* Summary:
I'm trying to set up syncrepl in my LDAP infrastructure. The logs on
my consumer show that syncrepl is failing to negotiate TLS when
connecting to the provider. Other LDAP commands such as ldapsearch and
sssd show no problem connecting using the same TLS configuration.
At this point, I don't have a good idea of how to continue debugging
this problem. Are there any more configuration items affecting TLS I
should be looking at? Or any way of getting more details on the TLS
nagotiation?
* The provider ("auth-00.[MYDOMAIN]"):
slapd 2.4.23 from openldap-servers-2.4.23-15.el6.x86_64 on Scientific
Linux 6. TLS is configured with
[cn=config]
olcTLSCACertificateFile: /etc/ssl/[MYCA].pem
olcTLSCertificateFile: /etc/ssl/certs/auth-00.crt.pem # Has
CN=auth-00.[MYDOMAIN]
olcTLSCertificateKeyFile: /etc/ssl/private/auth-00.key.pem
olcTLSVerifyClient: never
If I try:
$ ldapsearch -ZZ -x -H ldap://auth-00.[MYDOMAIN]/ uid=iain
it connects and cheerfully returns objects
* The provider ("auth-01.MYDOMAIN"):
Same slapd version, same package, same OS. syncrepl configuration:
olcSyncrepl: rid=001 provider=ldap://auth-00.[MYDOMAIN]:389
bindmethod=simple timeout=0
network-timeout=0 binddn="cn=syncrepl,dc=[MYDOMAIN]"
credentials="[MYPASSWORD]"
keepalive=0:0:0 filter="(objectClass=*)" searchbase="dc=[MYDOMAIN]" scope=sub
schemachecking=off type=refreshAndPersist retry="10 3 120 5 600 +"
starttls=critical
tls_cacert=/etc/ssl/MYCA.pem
* The error
Consumer:
Jan 28 11:53:12 auth-01 slapd[5595]: slapd starting
Jan 28 11:53:12 auth-01 slapd[5595]: slap_client_connect:
URI=ldap://auth-00.[MYDOMAIN]:389 Error, ldap_start_tls failed (-11)
Jan 28 11:53:13 auth-01 slapd[5595]: do_syncrepl: rid=001 rc -11
retrying (2 retries left)
Provider receiving syncrepl connection:
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 ACCEPT from
IP=[AUTH-01'S IP]:42669 (IP=0.0.0.0:389)
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 STARTTLS
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 RESULT oid= err=0 text=
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 closed (TLS
negotiation failure)
Provider receiving ldapsearch connection:
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 ACCEPT from
IP=[AUTH-01'S IP]:42765 (IP=0.0.0.0:389)
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 STARTTLS
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 RESULT oid= err=0 text=
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 TLS established
tls_ssf=256 ssf=256
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=1 BIND [...]
Thanks,
Iain.
--
Systems Engineer
KAUST Visualisation Laboratory
11 years, 7 months
ldapsearch -y works great, -w barks
by Randy Schultz
Howdy,
I'm confused as to why an operation with the -y filename works great, but the same operation with the -w pw
dies with "ldap_bind: Invalid credentials (49)".
The first file I've attached is with the -y, it works. The second is with the -w. I did notice the
difference where the working one had a "." at the end of the pw, which was not present when using the -w
option. To make sure I was not entering a typo on the commandline pw, I wrote a quick script, just a
#!/bin/sh
P=`cat p2`
echo "|$P|"
ldapsearch -v -d -1 -x -w "$P" -D cn=manager,dc=earlham,dc=edu -b ou=People,dc=earlham,dc=edu -h xaga
This also died with invalid credentials after printing out the pw.
Anybody have an idea what's going on?
--
Randy (schulra(a)earlham.edu) 765.983.1283 <*>
nosce te ipsum
11 years, 7 months
Trying to get passthrough auth working with OpenLDAP and Kerberos
by Chastity Blackwell
For the last two weeks I have been on a sojourn through the wonderful
world of LDAP, Kerberos, and SASL, which has had me banging my head
against the desk more often than not. Today I'm finally crying uncle and
asking for some help.
We're running Centos 5.4, currently with OpenLDAP for user info and
Kerberos for authentication, but we want to be able to use LDAP for
authentication on a bunch of devices that can't use Kerberos natively.
So I've been trying to get the passthrough auth working. So far, I think
I've made a lot of progress, but I've run into a wall. Kerberos and LDAP
are working in my testbed, and I can kinit and do an ldapwhoami no
problem. testsaslauthd also gives me a success when I run it. However,
when try to do a simple bind:
[chas@ldapsandbox]$ ldapwhoami -x -D
'uid=chas,ou=People,dc=test,dc=domain' -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
[chas@ldapsandbox]$
syslog shows this:
2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 fd=15 ACCEPT
from IP=10.17.136.50:55923 (IP=0.0.0.0:389)
2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 op=0 BIND
dn="uid=chas,ou=People,dc=test,dc=domain" method=128
2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: SASL [conn=6]
Failure: cannot connect to saslauthd server: No such file or directory
2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 op=0 RESULT
tag=97 err=49 text=
2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 fd=15 closed
(connection lost)
Meanwhile, the saslauthd I'm running with /usr/sbin/saslauthd -a
kerberos5 -d doesn't even show a connection or anything to the console.
Any idea why it can't connect to the saslauthd server?
Here's my OpenLDAP slapd.conf:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificateFile /etc/openldap/cacert.crt
TLSCertificateFile /etc/openldap/ldapsandbox.crt
TLSCertificateKeyFile /etc/openldap/ldapsandbox.key
authz-regexp uid=([^/]*),cn=gssapi,cn=auth uid=
$1,ou=People,dc=test,dc=domain
access to *
by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write
by * read
database bdb
suffix "dc=test,dc=domain"
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
And here's my /etc/sasl2/slapd.conf:
pwcheck_method: saslauthd
saslauthd_path: /var/run/sasl2/mux
Any ideas?
11 years, 7 months
