Project

General

Profile

Actions

Bug #8605

closed

OpenVPN wizard fails to populate LDAP fields

Added by Steve Wheeler over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
User Manager / Privileges
Target version:
Start date:
06/27/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4
Affected Architecture:
All

Description

If you run the OpenVPN wizard and choose LDAP in the first step it asks you to fill in the data required to create the LDAP client.
When you complete the wizard the LDAP authserver is created but the ldap_attr fileds are not filled.

        <authserver>
            <type>ldap</type>
            <refid>5b33a3407db2e</refid>
            <name>Test_Server</name>
            <host>10.0.0.1</host>
            <ldap_port>443</ldap_port>
            <ldap_urltype>SSL - Encrypted</ldap_urltype>
            <ldap_protver>3</ldap_protver>
            <ldap_scope>subtree</ldap_scope>
            <ldap_basedn><![CDATA[CN=test.com]]></ldap_basedn>
            <ldap_authcn><![CDATA[CN=Users]]></ldap_authcn>
            <ldap_binddn><![CDATA[admin]]></ldap_binddn>
            <ldap_bindpw><![CDATA[123456]]></ldap_bindpw>
            <ldap_attr_user><![CDATA[]]></ldap_attr_user>
            <ldap_attr_member><![CDATA[]]></ldap_attr_member>
            <ldap_attr_group><![CDATA[]]></ldap_attr_group>
        </authserver>
        <step1>
            <type>ldap</type>
        </step1>
        <step2>
            <authtype>Test_Server</authtype>
            <ip>10.0.0.1</ip>
            <port>443</port>
            <transport>tcp</transport>
            <scope>subtree</scope>
            <basedn>CN=test.com</basedn>
            <authscope>CN=Users</authscope>
            <userdn>admin</userdn>
            <passdn>123456</passdn>
            <nameattr>samAccountName</nameattr>
            <groupattr>cn</groupattr>
            <memberattr>memberOf</memberattr>
            <uselist>on</uselist>
        </step2>

Also the transport is changed from TCP to SSL though you could argue that choosing port 443 there is not valid for unencrypted LDAP.

Actions

Also available in: Atom PDF