Questions[ldapsearch](server)

Working to tie a server into ldap (active directory) and been struggling to get a simple bind working. The commands I have tried are:

ldapsearch -x -H ldap://192.168.10.10 -b "dc=example,dc=domain,dc=com" -D "cn=bind_user,dc=example,dc=domain,dc=com"-W
ldapsearch -x -H ldap://192.168.10.10 -b "dc=example,dc=domain,dc=com" -D "cn=bind_user,ou=Users,dc=example,dc=domain,dc=com" -W
ldapsearch -x -H ldap://192.168.10.10 -b "dc=example,dc=domain,dc=com" -D "cn=bind_user,cn=Users,dc=example,dc=domain,dc=com" -W

My LDAP server is active directory (windows 2016). My domain is example.domain.com. I do not believe I have anything special in my OU structure. Users live under the "Users" area like normal. Port 389 is opened via the firewall. Anonymous bind is blocked by default

Thoughts on why this simple bind would not be working? I have tried probably 20-ish flavors of the above with no luck.

The error I recieve is:

Enter LDAP Password:
ldap_bind: Invalid credentials (49)
    additional info: 80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, 
data 52e, v2580

Error tells me it is a bad credential or DN but can't see/comprehend what may be off. Thank you!

I have configured OpenLDAP to act as a proxy server via meta backend to do remote queries to two different companies' Active Directory servers. Everything works correctly in terms of pulling information from both domains. However... we have a case where two of the same sAMAccountname gets pulled and that causes issues for one of the web application we are using.(The web application requires one search base hence why I am going with a meta solution)

Here is my config

database meta
suffix   "dc=example,dc=com"
rootdn   "cn=admin,dc=example,dc=com"
rootpw   "supers3cr3tpass"
conn-ttl 3600
access to * by * auth
sizelimit 1

uri           "ldap://<companyA>/dc=example,dc=com"
readonly      yes
lastmod       off
suffixmassage "dc=example,dc=com" "dc=companyA,dc=com"
map attribute uid sAMAccountName
idassert-bind bindmethod=simple
        binddn="CN=UserA,DC=companyA,DC=corp"
        credentials="something"
idassert-authzFrom "*"
idle-timeout 300
keepalive 180:3:60
network-timeout 5
timeout 10


uri "ldap://companyB/dc=example,dc=com"
readonly      yes
lastmod       off
suffixmassage "dc=example,dc=com" "dc=companyB,dc=com"
map attribute uid sAMAccountName
idassert-bind bindmethod=simple
   binddn="CN=UserB,DC=companyB,DC=com"
   credentials="dontknow"
idassert-authzFrom "*"
idle-timeout 300
keepalive 180:3:60
network-timeout 5
timeout 10

I know there is a sizelimit clause where you can limit the search query but it does not apply to the rootdn which I am using to do the lookups/binds.

I am wondering...

1. Is there a way to return only one result from the search query?
2. Am I able to use another account that has the DN ending with dc=example,dc=com to do the bind and lookup? Theoretically, this should apply the sizelimit clause.

Any advice and answer is appreciated.

Thanks in advance!

I am running openldap 2.4.45. Is there anyway I can get the last login time of a user using authtimestamp or any other attribute?

I installed my Ca-cert like this:

chmod 644 /usr/local/share/ca-certificates/root-ca.crt && update-ca-certificates

this is successful but somehow ldapsearch with ldaps still won't connect to the server (Can’t contact LDAP server). without ssl the same command works.

/etc/ldap/ldap.conf:

TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

in this file I can find the correct certificate. also I can find it here:

/etc/ssl/certs/root-ca.pem

openssl tells me: Verification: OK when I run this command:

openssl s_client -connect my.domain.tld:7636

my ldapsearch-command:

ldapsearch -H ldaps://portal.domain.tld:7636 -b "dc=domain,dc=tld" -D "uid=mysynchuzer,CN=Users,DC=domain,DC=tld" -x -w MYPW

UPDATE: I tried openssl s_client command with -CAfile /etc/ssl/certs/ca-certificates.crt

which results in an error:

140568237548864:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:../crypto/asn1/asn1_lib.c:91:
140568237548864:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:../crypto/asn1/tasn_dec.c:1137:
140568237548864:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:572:
140568237548864:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:614:
140568237548864:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:646:Field=subject, Type=X509_CINF
140568237548864:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:646:Field=cert_info, Type=X509
140568237548864:error:0907400D:PEM routines:PEM_X509_INFO_read_bio:ASN1 lib:../crypto/pem/pem_info.c:196:
140568237548864:error:0B084009:x509 certificate routines:X509_load_cert_crl_file:PEM lib:../crypto/x509/by_file.c:205:

I have an AD environment and in ldapsearch, I am able to use SRV records in DNS to resolve the LDAP servers in the domain and in a site.

This works great on the usual ldap port on 389, with basic auth and STARTTLS.

However, some horrible clients won't do STARTTLS, or the vendor is unable to provide a method to configure it.[1] So we need to provide an option for LDAPS on 636.

In principle, I belive that creating ldaps SRV records and using the ldaps:/// URI should work. I've created 2 ldaps SRV records in the domain zone (there are 3 ldap hosts), but when I do ldapsearch and specify ldaps:///, all it's discovering are the ldap hosts.

Here's the ldapsearch command - here it's returning three DCs with _ldap SRVs on port 389

$ ldapsearch -v -H "ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom" -D "user" -W -b "DC=evl,DC=example,DC=com" -b "" -s base "(objectclass=*)" -d 1

ldap_url_parse_ext(ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom)
ldap_initialize( ldaps://EVLADC002vs.evl.example.com:389 ldaps://EVLADC001vs.evl.example.com:389 ldaps://EVLADC006vs.evl.example.com:389 )
ldap_create
ldap_url_parse_ext(ldaps://EVLADC006vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC001vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC002vs.evl.example.com:389)

However, the client machine can resolve the two SRVs for _ldaps, with port 636

$ dig -t SRV _ldaps._tcp.evl.example.com +short
0 100 636 EVLADC002vs.evl.example.com.
0 100 636 EVLADC001vs.evl.example.com.

Here's the LDAP SRV for comparision

$ dig -t SRV _ldap._tcp.evl.example.com +short
0 100 389 EVLADC001vs.evl.example.com.
0 100 389 EVLADC006vs.evl.example.com.
0 100 389 EVLADC002vs.evl.example.com.

If I query a specific server on ldaps, everything is fine

$ ldapsearch -H ldaps://evladc001vs.evl.example.com -D "user" -W -b "" -s base "(objectclass=*)"
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
currentTime: 20200213045340.0Z
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=evl,DC=example,DC=com
dsServiceName: CN=NTDS Settings,CN=EVLADC001VS,CN=Servers,CN=Server,CN=Sites,CN=Configuration,DC=evl,DC=example,DC=com
...  

I'd appreciate any advice on whether I'm missing some option or something else obvious re this issue.

[1]: Please don't start with lectures about using different products. Large enterprises have integration issues no matter what - try telling hospital systems to purchase different multimillion dollar software for their specific requirements