LDAP config

ghostadmin

Hi

i have some issues regarding LDAP connection to AD. I am switching from PAM to LDAP and VPN has been working fine so far.

in server.conf i am using:
plugin /usr/lib/openvpn/openvpn-auth-ldap.so /etc/openvpn/auth/auth-ldap.conf

auth-ldap.conf is were the fun starts

1. 389 vs 636
with:
URL "ldap://192.168.3.12:389"
TLSEnable no
BindDN "cn=openvpn,ou=ServiceAccounts,ou=x,ou=x,dc=ad,dc=myorg,dc=com"

the connection is working but i want to use encrypted connection. AD is already equiped with CA. So i changed to:
URL "ldap://192.168.3.12:636"
TLSEnable yes

but then the connection fails:
"Unable to enable STARTTLS"
Also TLSEnable no and/or ldaps://192.168.3.12 is not working.
I can connect with LDAP Browser providing same details just fine, server is working on 389 and 636, but why cant i secure connect with openvpn. I dont to specify any extra cert files, shouldnt OpenVPN just accept the self signed cert? Do i really need to export them certificates from AD ? Also i want to use 2 domain controllers to connect.

2. BaseDN

In almost all examples i found it is specified as cn=users,dc=domain,dc=com" which is working for any users there but i have different structure so tried to scope everything with dc=ad,dc=myorg,dc=com. But no users are working.
What do i need to specify if i got users in:
cn=users,dc=ad,dc=myorg,dc=com
and
ou=users,ou=x,ou=x,dc=ad,dc=myorg,dc=com

same goes for RequireGroup, also not working

<Authorization>
BaseDN "DC=ad,DC=myorg,DC=com"
SearchFilter "(&(sAMAccountName=%u))"
RequireGroup true
<Group>
BaseDN "ou=groups,ou=x,ou=x,dc=ad,dc=myorg,dc=com" (dc=ad,dc=myorg,dc=com also didnt work)
SearchFilter "(|(cn=VPN-Access))"
MemberAttribute memberOf
</Group>
</Authorization>

ghostadmin

Also SearchFilter for user is not working in this constellations:

"(&(uid=%u)(accountStatus=active))"
"(&(uid=%u))"
"(&(sAMAccountName=%u)(accountStatus=active))"

one additional working filter i have found is:
"(&(sAMAccountName=%u)(msNPAllowDialin=TRUE))"

The thing i got working is group section but the correct syntax is:
SearchFilter "(cn=VPN-Access)"
MemberAttribute "member"

openvpn-auth-ldap in debian looks like not updated a long time (2.0.3-6.1 since Jessie up to date)

mdibella

Port 636 is not STARTTLS enabled. It expects SSL/TLS negotiation on initial connection.

Also remember the the default configuration of MS DCs does not permit simple (plaintext) password binds over unsecure (non-TLS) channel.

ghostadmin

i tried also following:
URL "ldap://192.168.3.12:636"
URL "ldaps://192.168.3.12:636"
URL "ldaps://192.168.3.12"
with:
TLSEnable no

i found the following:
https://github.com/threerings/openvpn-auth-ldap/issues/65
https://www.openldap.org/lists/openldap-software/200202/msg00456.html

allow The client certificate is requested. If no
certificate is provided, the session
proceeds normally. If a bad certificate is
provided, it will be ignored and the session
proceeds normally.

demand | hard | true
These keywords are all equivalent, for
compatibility reasons. The client
certificate is requested. If no certificate
is provided, or a bad certificate is
provided, the session is immediately
terminated.

So i guess self signed = "bad certificate"

This i found also:
/* LDAP Settings */
TRString *_url;
BOOL _tlsEnabled;
BOOL _referralEnabled;
int _timeout;
TRString *_tlsCACertFile;
TRString *_tlsCACertDir;
TRString *_tlsCertFile;
TRString *_tlsKeyFile;
TRString *_tlsCipherSuite;
TRString *_bindDN;
TRString *_bindPassword;

/* Authentication / Authorization Settings */
TRString *_baseDN;
TRString *_searchFilter;
BOOL _requireGroup;
TRString *_pfTable;
TRArray *_ldapGroups;
BOOL _pfEnabled;
BOOL _passwordISCR;

Note it says tlsEnabled

# Uncomment and set to true to support OpenVPN Challenge/Response
# PasswordIsCR true

mdibella

It think you want

URL "ldaps://192.168.3.12:636"

this specifies secure connection using port 636.

I think OpenVPN might be failing the verify of the DC's certificate.

Try creating a local PEM file on the OpenVPN machine with the root of the DC's chain and adding

TLSCACertFile /usr/local/etc/ssl/ca.pem

to the <LDAP> section.

Also, if you are trying to filter out disabled accounts, the attribute to use is userAccountControl. It is bitmapped, so the expression to select enabled accounts looks like

(!(UserAccountControl:1.2.840.113556.1.4.803:=2))

ghostadmin

@mdibella
will try the options
found related: http://www.selfadsi.de/ads-attributes/user-userAccountControl.htm

do you have any idea why BaseDN is not working for sub ou ?

mdibella

Typically LDAP searches are conducted using one of three options, base, searches base level only, one-level, searches base and immediate children, subtree, searches all subcontainers. Is there an option for Scope?

mdibella

I took the time to review the source code and found the scope set statically to subtree (auth-ldap.m lines 333, 395 and 412).

I think you might need to use the full DN and not the CN of the group in the Authorization section becuase the memberOf attribure in AD schema is a multivalue containing a list of DNs.

ghostadmin

The group object not beeing a problem anymore, the user objects are

mdibella

Let's see your config...redact password

ghostadmin

working:
<LDAP>
URL "ldap://192.168.3.12:389"
BindDN "cn=openvpn,ou=ServiceAccounts,ou=x,ou=x,dc=ad,dc=myorg,dc=com"
Timeout 15
TLSEnable no
FollowReferrals yes
</LDAP>
<Authorization>
BaseDN "ou=Benutzer,ou=x,ou=x,dc=ad,dc=myorg,dc=com"
# User Search Filter
SearchFilter "(&(sAMAccountName=%u)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
RequireGroup true
<Group>
BaseDN "ou=Sicherheitsgruppen,ou=x,ou=x,dc=ad,dc=myorg,dc=com"
SearchFilter "(cn=VPN-Access)"
MemberAttribute "member"
</Group>
</Authorization>

If i use shortended path like:
BaseDN "dc=ad,dc=myorg,dc=com"

then i get:
LDAP user not found
or
LDAP search failed: Operations error (000004DC: LdapErr: DSID-0C090A37, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563)
depending where i use it

mdibella

You've definately got to solve the bind issue first. Try using LDP.exe https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772839(v=ws.10) to query the RootDSE https://docs.microsoft.com/en-us/windows/desktop/adschema/rootdse and confirm that the defaultNamingContext is the same as your BaseDN.

ghostadmin

That is reporting the same path as above ("dc=ad,dc=myorg,dc=com"):
Set rootDSE = GetObject("LDAP://rootDSE")
domainDN = rootDSE.Get("defaultNamingContext")
WScript.Echo domainDN

Shouldnt be a problem as the long version works without problem. Its like its not querying the substructure.

I saw that pfsense includes parameter "search scope" = subtree for ldap. Not sure how its working in openvpn plugin.

One thing i noticed, when i query (directory search) 192.168.3.12 with softerra ldap browser its trying also to authenticate with 2nd DC which is 192.168.3.14. Currently i have specified only 1 server in config.

mdibella

I only found three references to scope in the source code and they were all subtree. You might run tcpdump against the config with the unsecure connection and look at some pcaps.

ghostadmin

URL "ldap://192.168.3.12, ldap://192.168.3.14"

is this correct parameter?

mdibella

I don't know if that syntax is valid. I use the AD Kerberos Realm DNS name (i.e. ldap://ad.myorg.com) to return all of the DCs for the domain. The DNS client will use the first IP returned.

mdibella

I seeing different behavior without any SeachFilter. Try with SearchFilter commented out.