Issues with LDAP authentication about wg-portal

[TheOneWithTheBraid]

Thanks. The LDAP_SYNC_FILTER actually fixed the problem.

[h44z]

It is currently only supported to use email addresses as unique user identifiers or login names.

[TheOneWithTheBraid]

So, even in case I directly set LDAP_ATTR_EMAIL to something different, it does not work? Shouldn't the LDAP lookup work independent of the type of data specified?

Or is any kind of application-side data validation performed?

[TheOneWithTheBraid]

I found the issue:

wg-portal/internal/server/ldapsync.go

Lines 37 to 40 in edfecd5

	if ldapUsers[i].Attributes[s.config.LDAP.EmailAttribute] == "" ||
	ldapUsers[i].Attributes[s.config.LDAP.FirstNameAttribute] == "" ||
	ldapUsers[i].Attributes[s.config.LDAP.LastNameAttribute] == "" {
	continue

In our setup, we pay lots of attention to privacy and do not collect information like name or email address. As we have no data for

• LDAP.EmailAttribute
• LDAP.FirstNameAttribute
• LDAP.LastNameAttribute

, all users of our setup are skipped. It would be great to provide an option to allow users without these attributes or (even better) a direct configuration field to specify the requested LDAP lookup (e. g. (&(|(objectclass=inetOrgPerson)))) implying the provided email (or whatsoever) attribute from the config.

What do you think about this?

[h44z]

The problem is, that email addresses are used to link peers to users and thus an email address is required.
As a workaround, you could introduce a pseudo email address like [email protected].
I will possibly change the LDAP filter mechanism to support plain LDAP filter strings.

[TheOneWithTheBraid]

I see. Couldn't the peer user be liked by the UID too? Or is there technical need for mail addresses?

But yes, then, we will need to create pseudo mail addresses. Where would you recommend performing this within the source code?

[h44z]

The field that is used to link peers and users is called email and there are some validators (for example all UI requests) that require that field to be a valid email address.

The easiest way is to directly add a pseudo email to your LDAP entries. So you can use the LDAP_ATTR_EMAIL as intended.

If you want to change it in the code you would have to modify:

• https://github.com/h44z/wg-portal/blob/master/internal/authentication/providers/ldap/provider.go#L162 : use a pseudo email
• https://github.com/h44z/wg-portal/blob/master/internal/server/ldapsync.go#L36 : replace this filter and also store the the pseudo email address in ldapUsers[i].Attributes[s.config.LDAP.EmailAttribute]
• https://github.com/h44z/wg-portal/blob/master/internal/server/handlers_auth.go#L47: you might also want to replace the username here with the pseudo email address

That should be it...

Also make sure that the pseudo email addresses belong to your server or are undeliverable, otherwise WireGuard configurations might get leaked if they are send to some random email address...

[TheOneWithTheBraid]

I don't know whether it may be relevant for the upstream, but I performed the corresponding modifications in https://github.com/TheOneWithTheBraid/wg-portal.

[TheOneWithTheBraid]

I'm not sure why but these modifications do not seem to work properly, Maybe I need to adjust is somewhere else too?

Do you see any mistake here? TheOneWithTheBraid@aac3bb9

[h44z]

It is now possible to use an LDAP filter string like for example (&(objectClass=organizationalPerson)(!userAccountControl:1.2.840.113556.1.4.803:=2)(mail=*)) for the LDAP authentication and user synchronization: LDAP_LOGIN_FILTER and LDAP_SYNC_FILTER.
This is now the only way to filter users from LDAP, there are no other hardcoded filters in the code. Just make sure that the
LDAP_ATTR_EMAIL is always filled as this attribute is required by WireGuard Portal.

The configuration attributes LDAP_TYPE, LDAP_USER_CLASS and LDAP_ATTR_DISABLED are therefore no longer needed and supported.

[TheOneWithTheBraid]

I did not go through all the changes yet but does this great change include support for different identifiers than mail address too?

[h44z]

Partially, you can now use a different attribute for login. Internally, WireGuard Portal still requires a valid email address to link user profiles with WireGuard peers.

[TheOneWithTheBraid]

Is there any plan to update this? We still cannot use the portal because we don't collect email addresses for privacy reasons? Are there any other blocking mechanisms preventing from using a generally configurable parameter instead of email?

[h44z]

You can use any ldap attribute for login. If you do not use email adresses, simply generate some randome ones and use those. I will change this requirement in version 2 of wg-portal, but I have no release date yet.

[TheOneWithTheBraid]

Yeah, we already generate random mail addresses. Our problem is that they are random, so no one - even not the user themself - knows them except of the LDAP server and some other incompatible services requireing a mail attribute (e.g. Nextcloud Registration). But as of now I don't see a way of using another identifier than mail for login, right? I cannot use uid as identifier instead of mail, even if I set LDAP_LOGIN_FILTER=(&(objectClass=organizationalPerson)(uid={{login_identifier}})) right?

[h44z]

LDAP_LOGIN_FILTER=(&(objectClass=organizationalPerson)(uid={{login_identifier}})) should work fine

[TheOneWithTheBraid]

Okay, interesting, because we still get the known errors:

wg-portal_1  | ERRO[2021-09-10 11:51:39] failed to fetch users from ldap: failed to search in ldap: LDAP Result Code 32 "No Such Object":  

Our whole LDAP config is:

# LDAP Settings
LDAP_ENABLED=true
LDAP_URL=ldap://ip:389
LDAP_STARTTLS=false
LDAP_CERT_VALIDATION=false
LDAP_BASEDN=cn=users,cn=accounts,dc=example,dc=com
LDAP_USER=uid=admin,cn=users,cn=accounts,dc=example,dc=com
LDAP_PASSWORD=secret
LDAP_ADMIN_GROUP=cn=admins,cn=users,cn=accounts,dc=example,dc=com
LDAP_LOGIN_FILTER=(&(objectClass=organizationalPerson)(uid={{login_identifier}}))
LDAP_SYNC_FILTER=(&(|(objectclass=inetOrgPerson)))
LDAP_TYPE=OpenLDAP
#LDAP_USER_CLASS=inetOrgPerson
LDAP_ATTR_EMAIL=UID
LDAP_ATTR_FIRSTNAME=displayName
LDAP_ATTR_LASTNAME=uid

ldapsearch perfectly works using these filters.

Do you see any misconfiguration there?

[h44z]

This error is not related to the authentication backend. It is thrown while synchronizing ldap users to the database (LDAP_SYNC_FILTER is used here). The syncfilter looks incorrect to me... there is a AND and OR condition that does not make any sense. Replace that filter with LDAP_SYNC_FILTER=(objectclass=inetOrgPerson). You also specify the UID attributes inconsistent, use either all lowercase or uppercase characters, I think the attribute name should be specified in lowercase characters.