dante   Frontpage - Dante - Download - Status - Support - Modules - Docs - Links - Survey - GDPR
 

Dante Module Documentation
LDAP Module (Dante 1.4.3)

Description

The LDAP module extends the functionality of the Dante SOCKS server by integrating LDAP-based authentication and authorization.
  • Authentication The ldapauth authentication method verifies a given username/password combination, provided to Dante by the SOCKS client, with the appropriate LDAP server.

    If the username/password combination does not match that stored at the LDAP server, Dante blocks the client.
  • Authorization The ldap.group authorization functionality supports access control based on a users LDAP group membership. The Privilege Account Certificate (PAC) functionality furthermore adds Kerberos group based user access control.

    This can be used to limit the network access of different SOCKS users based on their LDAP and/or Kerberos group membership.
The location of LDAP servers in a network can be specified either explicitly in the Dante server's configuration file, or it can be discovered automatically by the LDAP module. This makes it easier to integrate Dante in existing GSSAPI/LDAP setups, e.g., networks using Active Directory.

LDAP server identity

In some configurations, the LDAP module will be able to do most of the work involved in identifying and contacting the LDAP servers in a network without further configuration required in Dante.

If the username provided to Dante by the SOCKS client contains a domain extension, the LDAP module determines the LDAP server automatically using the following method to obtain a list of available servers:
  1. Extract the domain name from the username.

    E.g., DOMAIN.COM from user@DOMAIN.COM, either when GSSAPI authentication is used, or if the username includes a domain with username/password authentication.
  2. Perform a DNS SRV record lookup of the domain name (typically available in a Windows environment with Active Directory):
    • Without SSL: from _ldap._tcp.DOMAIN.COM.
    • With SSL: from _ldaps._tcp.DOMAIN.COM.

      If this entry does not exist, follow the same procedure as Without SSL.
  3. Perform a DNS A record lookup of DOMAIN.COM.
  4. Use /etc/hosts file entry for DOMAIN.COM.
  5. Sort entries by weight and priority and remove duplicates.
If the username does not contain any domain extension, a pre-configured LDAP URL can be set in the Dante configuration file and used to verify the LDAP group membership of users.

The module authenticates to the LDAP server using SASL/GSSAPI with the appropriate entry of the GSSAPI or LDAP specific keytab, or the username/password provided as part of the LDAP URL.

Configuration examples

This section starts with some general templates for Dante configurations, without LDAP functionality, and then shows how these templates can be modified and extended to use the LDAP module functionality in various usage scenarios.

Dante PAM configuration -- no LDAP functionality

Inferno Nettverk A/S provides Dante in a package that consists of both a SOCKS client and a SOCKS server. While part of the same package, they work independent of each others and one is not required for the other.

When PAM is used to verify usernames/passwords in the server, the method username should be used in the client.

Client configuration

logoutput: socks.log
# debug: 1

route {
   from: 0/0 to: 0/0 via: 10.0.0.1 port = 1080
   proxyprotocol: socks_v5
   method: username
}
NOTE: The client username method sends the username/password in plaintext and may not be appropriate for use unless combined with other security mechanisms.

Server configuration

With PAM, the Dante server will usually need root privileges to verify the username/password combination received from the user, though this will depend on the PAM configuration on the given system, which is controlled externally to Dante. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: pam.username

user.privileged    : root
user.notprivileged : sockd

client pass {
   from: 0/0 to: 0/0
   log: connect disconnect error
}

socks pass {
   from: 0/0 to: 0/0
   log: connect disconnect error
}

LDAP Authentication

The LDAP Authentication mechanism uses the ldapauth method for authentication. Like with PAM, the client configuration file needs to specify the username method to supply the username/password to the Dante server.

Client configuration

logoutput: socks.log
# debug: 1

route {
   from: 0/0 to: 0/0 via: 10.0.0.1 port = 1080
   proxyprotocol: socks_v5
   method: username
}
NOTE: The client username method sends the username/password in plaintext and may not be appropriate for use unless combined with other security mechanisms.

Server configuration -- Automated server detection

In contrast with PAM, the Dante server does not require root privileges to verify the username/password combination received from the user.

The configuration given next requires the LDAP server to be findable via DNS. Unless this functionality is disabled, or an LDAP server is explicitly specified in the Dante configuration file, the LDAP module will attempt to automatically determine the name and address of the LDAP server. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: ldapauth # ldap authentication

user.privileged    : sockd # extra privileges not required
user.notprivileged : sockd

client pass {
   from: 0/0 to: 0/0
   log: connect disconnect error
}

socks pass {
   from: 0/0 to: 0/0
   log: connect disconnect error
}

Server configuration -- Hardcoded server configuration

The location of the LDAP server, or servers, can also be specified directly in the Dante configuration file.

This configuration specifies the simplest and most compact way of providing the server information. The ldap.auth.url keyword is used to specify the name of the LDAP server, along with the username and password to use for accessing the LDAP server. SSL is disabled in this example. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: ldapauth # ldap authentication

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 0/0 to: 0/0
   log: connect disconnect error
}

socks pass {
   from: 0/0 to: 0/0
   log: connect disconnect error

   ldap.auth.auto.off: yes # disable automatic ldap server lookup
   ldap.auth.ssl: no       # disable ssl

   # use the below URL, with username and password, for accessing
   # the LDAP server.
   ldap.auth.url: ldap://user:pass@ldap.example.com/basedn
}

Server configuration -- SSL protected LDAP lookup

This is a variant of the previous configuration, with the LDAP server hardcoded, and SSL enabled for the connection between the Dante server and the LDAP server.

The ldap.auth.url keyword is used to specify the name of the LDAP server, along with the username and password to use for accessing the LDAP server. SSL is enabled in this example. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: ldapauth # ldap authentication

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 0/0 to: 0/0
   log: connect disconnect error
}

socks pass {
   from: 0/0 to: 0/0
   log: connect disconnect error

   ldap.auth.auto.off: yes  # disable auto ldap server lookup
   ldap.auth.certcheck: yes # certificate check enabled

   # LDAP server, specified with ldaps url
   ldap.auth.url: ldaps://user:pass@ldap.example.com/basedn
}

Server configuration -- SASL/GSSAPI LDAP lookup

The communication between the Dante server and the LDAP server can also be done over SASL/GSSAPI: 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: ldapauth none

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 0/0 to: 0/0
}
socks pass {
   from: 0/0 to: 0/0

   ldap.auth.keytab: /etc/sockd-ldap.keytab
   ldap.auth.domain: EXAMPLE.COM
   ldap.auth.url: ldaps://ldap.example.com
}

Dante GSSAPI configuration -- no LDAP functionality

With GSSAPI, users already authenticated to a Windows AD server or similar can automatically authenticate to the Dante SOCKS server, which will result in all communication between the client and the Dante server being encrypted.

Client configuration

logoutput: socks.log
# debug: 1

route {
   from: 0/0 to: 0/0 via: 10.0.0.1 port = 1080
   proxyprotocol: socks_v5
   method: gssapi
}

Server configuration

The Dante server requires a keytab file, that is specified in the client pass rule. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: gssapi

user.privileged    : root
user.notprivileged : sockd

client pass {
   from: 0/0 to: 0/0
   log: connect disconnect error

   # keytab
   gssapi.keytab: /etc/sockd.keytab
}

socks pass {
   from: 0/0 to: 0/0
   log: connect disconnect error
}

LDAP Authorization

The LDAP authorization functionality is typically used with GSSAPI authentication, with membership to a LDAP group required for users to have sessions forwarded by the Dante SOCKS server.

For Windows clients, the OpenText (formerly Hummingbird) client can be used (see https://connectivity.opentext.com/products/socks-client.aspx).

As with the LDAP authentication configurations, the LDAP module will by default attempt to automatically locate the LDAP server via DNS. The config file below does not specify any LDAP server or disable the automatic lookup, so DNS will be used. The name of the LDAP server, and how communication between the LDAP module and the LDAP server should be handled, can be configured for the LDAP authorization functionality in the same way as for the LDAP authentication functionality, with the difference being that instead of ldap.auth, the prefix is ldap (e.g., ldap.url, etc.).

Client configuration

No changes are needed to the GSSAPI client configuration: 
logoutput: socks.log
# debug: 1

route {
   from: 0/0 to: 0/0 via: 10.0.0.1 port = 1080
   proxyprotocol: socks_v5
   method: gssapi
}

Server configuration -- Limiting access to web/http

The rules below shows an example of how one can limit access to web sites from clients on the 10.0.0.0/8 network to members of the SOCKS_ALLOW LDAP group. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: gssapi

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 0/0 to: 0/0
   log: connect disconnect error

   # keytab for GSSAPI authentication
   gssapi.keytab: /etc/sockd.keytab
}

pass {
  from: 10.0.0.0/8 to: 0/0 port = http

  # only members of LDAP group can access via this rule.
  ldap.group: SOCKS_ALLOW
}
For an OpenLDAP server with a rfc2307bis schema or an Active Directory server, with the configuration example given in the Appendix, User1 and User2 will be allowed, whereas User3 will be refused access.

Server configuration -- Limiting access to SSL VPNs

The next rule, if placed before other general rules, shows how one can limit access for temporary staff on the 10.0.0.0/8 network to only a specific work related site. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: gssapi

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 10.0.0.0/8 to: 0/0
}

pass {
   from: 10.0.0.0/8 to: sslvpn.example.com port = 443
   command: connect

   ldap.group: Temporary
   ldap.filter: (uid
   ldap.attribute: employeeType
}

pass {
  from: 10.0.0.0/8 to: 0/0 port = 443
  command: connect

  ldap.group: Permanent
  ldap.filter: (uid
  ldap.attribute: employeeType
}
Assuming the OpenLDAP configuration in the Appendix example is used, the temporary user User3 is only allowed to connect to sslvpn.example.com on port 443 whereas the permanent users User1 and User2 can connect to any secure web site via https.

Server configuration -- Limiting ftp to company employees only

The next rule shows how one can limit access to ftp sites to company employees on the 10.0.0.0/8 network only. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: gssapi

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 10.0.0.0/8 to: 0/0
}

pass {
  from: 10.0.0.0/8 to: 0/0 port = ftp

  ldap.group: MyCompany
  ldap.keeprealm: yes
  ldap.filter.ad: (userprincipalname
  ldap.attribute.ad: company
}

block { # other users are not allowed to connect to FTP servers.
  from: 0/0 to: 0/0 port = ftp
}

pass { # access to all-non FTP ports allowed for everyone.
  from: 0/0 to: 0/0
}
Assuming the Active Directory example in the Appendix is used, User3 is only allowed to connect to ftp data whereas the users User1 and User2 are not allowed.

Server configuration -- LDAP URL usage

The next rule shows how one can limit access to ftp sites for company employees on the 10.0.0.0/8 network without requiring GSSAPI authentication. An LDAP URL with a directly specified username (here user) and password (here pass) is used for authentication.

In this example, two LDAP servers are specified, with the second server (ldap2) contacted only if ldap1 is not available. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: gssapi

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 10.0.0.0/8 to: 0/0
}

pass {
  from: 10.0.0.0/8 to: 0/0 port = ftp
  command: connect
  ldap.group: SOCKS_ALLOW
  ldap.auto.off: yes
  ldap.url: ldap://user:pass@ldap1.example.com:389/OU=SALES,DC=MYCOMPANY,DC=COM
  ldap.url: ldap://user:pass@ldap2.example.com:389/OU=SALES,DC=MYCOMPANY,DC=COM
}

block { # other users are not allowed to connect to FTP servers.
  from: 0/0 to: 0/0 port = ftp
}

pass { # access to all-non FTP ports allowed for everyone.
  from: 0/0 to: 0/0
}

PAC Authorization

The Privilege Account Certificate (PAC) functionality relies on the SOCKS client using GSSAPI authentication with the Dante server, and uses the Microsoft Kerberos PAC authorisation-data field. This is an extension element of the authorization-data field contained in the client's Kerberos ticket (See https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/).

PAC requires the user to have authenticated with GSSAPI. For Windows clients, the OpenText (formerly Hummingbird) client can be used (see https://connectivity.opentext.com/products/socks-client.aspx).

Finding PAC Group SIDs

To get the SID from an Active Directory Server use ldapsearch, or a similar command with SASL/GSSAPI authentication to an Active Directory server. 
ldapsearch -LLL -H ldap://dc1.samba.home:389 -s sub \
   -b "OU=testgroups,dc=samba,dc=home" "(CN=SOCKS_ALLOW)" objectsid
The above command should produce output similar to the below: 
filter: (cn=SOCKS_ALLOW)
requesting: objectsid
dn: CN=SOCKS_ALLOW,OU=TestGroups,DC=samba,DC=home
objectSid:: AQUAAAAAAAUVAAAA3e5/WdBj9hHz1/+pVgQAAA==
The objectSid value can then be converted with the convert_sid tool included with the LDAP module: 
Base64 encoded: AQUAAAAAAAUVAAAA3e5/WdBj9hHz1/+pVgQAAA==
Hexadecimal: 01 05 00 00 00 00 00 05 15 00 00 00 dd ee 7f 59 d0 63 f6
             11 f3 d7 ff a9 56 04 00 00
SID: S-1-5-21-1501556445-301360080-2852116467-1110
The SID value can then be used with the pac.sid keyword.

Other ways to get the ObjectSid are via a LDAP admin tool or Microsoft's Active Directory Management Tools. These tools can be run from a Windows 10 desktop, see Figure 3 and Figure 4 for examples.

Client configuration

No changes are needed to the GSSAPI client configuration: 
logoutput: socks.log
# debug: 1

route {
   from: 0/0 to: 0/0 via: 10.0.0.1 port = 1080
   proxyprotocol: socks_v5
   method: gssapi
}

Server configuration -- PAC group limiting

The below rule shows how one can limit the access to web sites from the clients on the 10.0.0.0/8 net to members of the SOCKS_ALLOW group, with the PAC id for the group obtained from the LDAP server, as described above. 
logoutput: /var/log/sockd.log
# debug: 1

internal: eth0 port = 1080
external: eth1

socksmethod: gssapi

user.privileged    : sockd
user.notprivileged : sockd

client pass {
   from: 10.0.0.0/8 to: 0/0
}

pass {
   from: 10.0.0.0/8 to: 0/0 port = http
   pac.sid: S-1-5-21-1501556445-301360080-2852116467-1110
}

Error and setup debugging

The LDAP module involves a diverse set of protocols and systems; SOCKS, GSSAPI, LDAP, SASL, SSL/TLS, etc. For most of these protocols there are also multiple implementations, meaning that there are many components that need to work together, giving many possible combinations and error situations.

We have tried to make Dante and the LDAP module provide debug information that makes diagnosing configuration problems easier, but there are still other sources of information that might need to be consulted to perform debugging in some cases. This section provides an overview of how to simplify debugging LDAP-related Dante configurations, along with some examples of possible errors.

Dante and system logging

There are several potential sources of helpful information that can be used when debugging problems related to GSSAPI and LDAP in Dante.

Dante log files

Dante attempts to provide useful information in case of session establishment failures, so the Dante logs are a good place start. The information that is available to Dante can be limited by what is provided by external APIs, but in many situations the Dante logs can provide enough information to determine the source of a problem.

The Dante sockd.conf server configuration file specifies how and where normal logging show be done via the logoutput keyword.

Dante debug logging

Additional Dante debug information can be enabled by adding the debug: N keyword to the Dante sockd.conf file, or starting Dante with the -d N option, where N is the verbosity level. Relevant values for N are 1 and 2, with 1 likely being the most useful.

When debugging problems, it can be practical to start Dante manually to make it simpler to adjust command line parameters and environment variables. This involves running Dante without the -D (detach) option, as is shown below, assuming Dante is installed as /usr/sbin/sockd and that the path to the server configuration file is /etc/sockd.conf: 
/usr/sbin/sockd -d1 -f /etc/sockd.conf
Logging will still be performed as specified in sockd.conf, but Dante can be terminated with Ctrl-c and any stderr output from linked libraries will be seen.

Note that Dante should be started from the user that normally starts Dante, either root or any user specific to Dante.

LDAP module debug logging

  The LDAP module keywords ldap.debug and ldap.auth.debug enable logging of extra debug information by the Dante server. When linked with OpenLDAP, the OpenLDAP debug level will also be set to the specified value.

The special value -1 will enable both full OpenLDAP logging and extra log output from the LDAP module, which will provide additional details on the communication between Dante and LDAP/AD servers.

Note that the OpenLDAP libraries log to stderr, so Dante should be started manually from the shell, as shown above, to ensure the log output can be seen.

Kerberos log files

For problems related to Kerberos/GSSAPI, the Kerberos log files might provide useful information not available in the Dante log file.

The location of the Kerberos log file can usually be found in the Kerberos configuration file, which will typically contain a lines like the below, that specify the path to the log file: 
[logging]
   kdc = FILE:/var/log/krb5kdc.log

Kerberos client tracing

For MIT Kerberos, additional logging can be enabled that show more details about the operations performed by the Kerberos libraries.

This is controlled via the KRB5_TRACE environment variable: 
KRB5_TRACE=krb5client.log
If networking programs that communicate with the Dante SOCKS server using GSSAPI authentication are run with this variable set, the krb5cilent.log file should get a trace of operations performed as part of the authentication process.

Ensure that the user running the networking programs has permission to write to the trace file.

Kerberos server tracing

For MIT Kerberos, trace logging can also be enabled that provides additional information about the Kerberos related operations performed in the Dante server.

This requires the KRB5_TRACE variable to be set also for the Dante server, which can be done by starting Dante like this: 
KRB5_TRACE=krb5server.log
/usr/sbin/sockd -d1 -f /etc/sockd.conf
Ensure that the user running the Dante server can write to the trace file.

LDAP server log files

LDAP server log files might also provide useful information, such as details on what connections are received and reasons for request failures.

Failure examples

This section provides some examples of commonly observed error conditions and how they can be debugged via log files.

Invalid ldap.keytab value

The ldap.keytab keyword can be used to set a keytab file to be used when starting an LDAP lookup session. If the keytab file specified does not exist, ldap.group lookups can fail and warnings like those below might get logged by the Dante server.
warning: krb5_read_keytab(): error starting keytab sequence: No such file or directory warning: krb5_create_cache(): reading keytab /nonext into list failed: No such file or directory warning: krb5_create_cache(): starting keytab scan failed: No such file or directory warning: ldapgroupmatches(): setup of Kerberos credential cache failed: EXAMPLE.COM, /nonext: Operation not permitted warning: ldapgroupmatches(): cannot determine which LDAP server to use
The given warnings show that Dante was unable to read the keytab file, named nonext in this example, due to the file not existing.

For this type of problem, the warnings logged by Dante provide sufficient information to determine the source of the problem.

Invalid ldap.url username/password

An username or password in the ldap.url keyword specifying invalid access credentials for the LDAP server, will result in blocked ldap.group lookups.

This can result in Dante log warnings like the following:
warning: ldapgroupmatches(): binding to LDAP server ldap://ldap.example.com:389 with username/password failed: Invalid credentials: no additional error warning: ldapgroupmatches(): initialization of LDAP connection failed
The first warning indicates that there is a problem with the credentials for binding to the LDAP server. The logs of the LDAP server might have additional information that might be helpful.

Mismatching certificate

If SSL/TLS is used to encrypt communication with the LDAP server and ldap.certcheck is set to enable server certificate verification, ldap.group lookups should fail if there is a problem with the certificate. This can result in warnings like the following:
warning: tool_ldap_open(): start_tls attempt failed for LDAP ldap.example.com:389: Can't contact LDAP server: no additional error warning: ldapgroupmatches(): binding to LDAP server ldaps://ldap.example.com:389 with username/password failed: Can't contact LDAP server: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get local issuer certificate) warning: ldapgroupmatches(): initialization of LDAP connection failed
For this error, the Dante logs provide sufficient information to determine the reason for the error. In this case, the problem appears to be related to the Dante server not having the certificate information required to verify the certificate of the LDAP server available.

Syntax for LDAP user authentication

The keywords available for LDAP-based authentication are listed below. These statements are generally only used as a part of Dante socks-rules.

Some keywords can be repeated to specify multiple values, such as multiple LDAP servers, while other keywords should only be specified once per rule. Unless explicitly mentioned, the given keywords should at most be specified once per rule.

ldap.auto.off

Syntax: ldap.auto.off: <no|yes>

Disable automatic determination of LDAP server. The default value is no.

ldap.auth.basedn

Syntax: ldap.auth.basedn: <base dn>

Syntax: ldap.auth.basedn.hex: <base dn>

Syntax: ldap.auth.basedn.hex.all: <base dn@domain.com>

Specify the base dn to use for searches on LDAP server. The hex variant expects only the base DN in hex UTF-8 encoding, while the hex.all variant expects both the base DN and domain name in hex UTF-8 encoding.

These statements can be repeated.

ldap.auth.certcheck

Syntax: ldap.auth.certcheck: <no|yes>

Require or disable SSL certificate check when connecting to LDAP server. The default value is no.

ldap.auth.certfile

Syntax: ldap.auth.certfile: <filename>

With compiled with OpenLDAP, specify the path to a CA certificate file.

ldap.auth.certpath

Syntax: ldap.auth.certpath: <pathname>

When compiled with OpenLDAP or the Sun/Mozilla LDAP SDK, specify the path to the certificate database.

ldap.auth.debug

Syntax: ldap.auth.debug: <debug level>

Set the debug level for LDAP authentication code. With OpenLDAP, also set the library debug level. The default is 0 (off). Set to -1 for full debug output. The OpenLDAP binary will send debug output to stderr, so to be visible the server must be started without the -D option.

The OpenLDAP debug levels are defined here: https://openldap.org/doc/admin24/runningslapd.html.

ldap.auth.domain

Syntax: ldap.auth.domain: <domain>

Set the default Kerberos domain to be used for GSSAPI authentication against the LDAP server. It also determines the LDAP server as ldap://<domain> by resolving the domain name via DNS.

ldap.auth.filter

Syntax: ldap.auth.filter: <filter>

The filter argument is the search filter for the LDAP server. The default filter is (samaccountname=%s) for Active Directory and (uid=%s) for other LDAP servers and assumes a rfc2307bis schema.

ldap.auth.keytab

Syntax: ldap.auth.keytab: <keytab>

Set the file name of the keytab file containing the Kerberos principals for authentication to the LDAP servers. If this value is not set, the value of gssapi.keytab will be used. If gssapi.keytab is also not set, the default will be /etc/sockd.keytab.

ldap.auth.port

Syntax: ldap.auth.port: <port>

Set the port number to be used when contacting the LDAP port (not LDAPS port) on the LDAP server. Used for automatic LDAP server determination if no SRV DNS records exist.

The default value is 389.

ldap.auth.port.ssl

Syntax: ldap.auth.port.ssl: <port>

Set the port number to be used when contacting the LDAP SSL port on the LDAP server. Used for automatic LDAP server determination if no SRV DNS records exist.

The default value is 636.

ldap.auth.server

Syntax: ldap.auth.server: <server@domain.com>

Set the server name of the LDAP server for domain domain.com. This setting avoids the automated server determination via DNS SRV or A records.

This statement can be repeated.

ldap.auth.ssl

Syntax: ldap.auth.ssl: <no|yes>

Require SSL/TLS for LDAP connection. The default value is yes.

ldap.auth.url

Syntax: ldap.auth.url: <url>

Specify LDAP server information in URL format:
ldap(s)://<username>:<password>@<host:port>/<basedn>

This statement can be repeated.

Syntax for LDAP group checks

The keywords available for LDAP-based authentication are listed below. These statements are generally only used as a part of Dante socks-rules.

Some keywords can be repeated to specify multiple values, such as multiple LDAP servers, while other keywords should only be specified once per rule. Unless explicitly mentioned, the given keywords should at most be specified once per rule.

ldap.attribute

Syntax: ldap.attribute: <attribute>

Syntax: ldap.attribute.hex: <attribute>

Sets the attribute to use when matching the ldap.group value against LDAP users group membership. The module will search recursively through groups. The default value is cn.

The hex variant sets the attribute using hex UTF-8 encoding.

ldap.attribute.ad

Syntax: ldap.attribute.ad: <attribute>

Syntax: ldap.attribute.ad.hex: <attribute>

Sets the attribute to use when matching the ldap.group value against LDAP users group membership, when the LDAP server is an Active Directory server. The module will search recursively through groups. The default attribute value is memberof.

The hex variant sets the attribute using hex UTF-8.

ldap.auto.off

Syntax: ldap.auto.off: <no|yes>

Disable automatic determination of LDAP server. The default value is no, giving automatic lookup.

ldap.basedn

Syntax: ldap.basedn: <base dn|base dn@domain.com>

Syntax: ldap.basedn.hex: <base dn>

Syntax: ldap.basedn.hex.all: <base dn@domain.com>

The parameters are defined as follows:
  • base dn base DN for LDAP search for any LDAP server.
  • base dn@domain.com the base DN for LDAP search for LDAP server for domain domain.com.
The hex variant expects only the base DN in hex UTF-8, while the hex.all variant expects both the base DN and domain name in hex UTF-8.

These statements can be repeated.

ldap.certcheck

Syntax: ldap.certcheck: <no|yes>

Require or disable SSL certificate check when connecting to LDAP server. The default value is no.

ldap.certfile

Syntax: ldap.certfile: <filename>

With compiled with OpenLDAP, specify the path to a CA certificate file.

ldap.certpath

Syntax: ldap.certpath: <pathname>

When compiled with OpenLDAP or the Sun/Mozilla LDAP SDK, specify the path to the certificate database.

ldap.debug

Syntax: ldap.debug: <debug level>

Set the debug level for LDAP authentication code. With OpenLDAP, also set the library debug level. The default is 0 (off). Set to -1 for full debug output. The OpenLDAP binary will send debug output to stderr, so to be visible the server must be started without the -D option.

The OpenLDAP debug levels are defined here: https://openldap.org/doc/admin24/runningslapd.html.

ldap.domain

Syntax: ldap.domain: <domain>

Set the default Kerberos domain to be used for GSSAPI authentication against the LDAP server. It also determines the LDAP server as ldap://<domain> by resolving the domain name via DNS.

ldap.filter

Syntax: ldap.filter: <filter>

Syntax: ldap.filter.hex: <filter>

The filter argument is the search filter for the LDAP server. The default filter is (memberuid=%s) and assumes a rfc2307bis schema.

The hex variant sets the filter using hex UTF-8.

ldap.filter.ad

Syntax: ldap.filter.ad: <filter>

Syntax: ldap.filter.ad.hex: <filter>

Set search filter for an Active Directory server. The default filter is (samaccountname=%s).

The hex variant sets the filter using hex UTF-8.

ldap.group

Syntax: ldap.group: <ldap-group|ldap-group@|ldap-group@domain.com>

Syntax: ldap.group.hex: <ldap-group>

Syntax: ldap.group.hex.all: <ldap-group@domain.com>

The parameters are defined as follows:
  • ldap-group name of LDAP group to be used for any user.
  • ldap-group@ name of LDAP group to be used for users who have a domain extension in their username (e.g., user@domain1.com).
  • ldap-group@domain.com name of LDAP group to be used only for users who have a domain extension of domain.com in their username.
The hex variant expects only the group in hex UTF-8, while the hex.all variant expects both the group and domain name in hex UTF-8.

These statements can be repeated.

ldap.keeprealm

Syntax: ldap.keeprealm: <no|yes>

Keep the realm name when comparing username with LDAP user attribute. The default value is no.

ldap.keytab

Syntax: ldap.keytab: <keytab>

Set the file name of the keytab file containing the Kerberos principals for authentication to the LDAP servers. If this value is not set, the value of gssapi.keytab will be used. If gssapi.keytab is also not set, the default will be FILE:/etc/sockd.keytab.

ldap.mdepth

Syntax: ldap.mdepth: <maximal search depth>

Set the maximal search depth of recursive group searches in Active Directory. The default value is 0.

ldap.port

Syntax: ldap.port: <port>

Set the port number to be used when contacting the LDAP server. Used for automatic LDAP server determination if no SRV DNS records exist.

The default value is 389.

ldap.port.ssl

Syntax: ldap.port.ssl: <port>

Set the SSL port number to be used when contacting the LDAP server. Used for automatic LDAP server determination if no SRV DNS records exist.

The default value is 636.

ldap.server

Syntax: ldap.server: <server@domain.com>

Set the server name of the LDAP server for domain domain.com. This setting avoids the automated server determination via DNS SRV or A records.

This statement can be repeated.

ldap.ssl

Syntax: ldap.ssl: <no|yes>

Require SSL/TLS for LDAP connection. The default value is no.

ldap.url

Syntax: ldap.url: <url>

Specify LDAP server information in URL format:
ldap(s)://<username>:<password>@<host:port>/<basedn>

This statement can be repeated.

Syntax for PAC group checks

The kewords available for PAC-based group checks are listed below. These statements are generally only used as a part of Dante socks-rules.

Some keywords can be repeated to specify multiple values, such as multiple groups, while other keywords should only be specified once per rule. Unless explicitly mentioned, the given keywords should at most be specified once per rule.

pac.sid

Syntax: pac.sid: <group-sid>

Syntax: pac.sid.b64: <group-sid>

Set the SID of an Active Directory (or Samba) security group. The socks-rule these keywords are used in will only match for users that are members of the specified groups. The b64 variant expects the SID in base64 encoded format.

These statements can be repeated.

pac.off

Syntax: pac.off: <yes|no>

Enable or disables the caching of the objectSid for authorisation, the default in on.

When used with the ldap.group functionality, the group objectSid of an Active Directory group will automatically be cached and used for verification if GSSAPI authentication is used. This avoids additional LDAP lookups and speeds up the authorisation process.

LDAP module related compile-time values

In addition to configuration that can be changed by changing the Dante server configuration file, the Dante server also uses various timeout values as defined at compile-time. Normally there is no need to change these, but if necessary, they can be changed by the operator before recompiling Dante.

The following values are defined in the file include/sockd.h, and can be changed at compile-time if so desired. All values are given in seconds:
  • SOCKD_LDAP_DEADTIME the time to wait before a non-responsive LDAP server should be retried.
  • SOCKD_LDAP_SEARCHTIME the maximum time an LDAP search can take before Dante will give up waiting for a response.
  • SOCKD_LDAP_TIMEOUT the maximum time a connection to a LDAP server can take to establish before Dante will give up on waiting for the connection to be established.
The following value is defined in include/config.h:
  • SOCKD_LDAPCACHE_TIMEOUT is the maximal time a LDAP group result is cached.
Should it be necessary to change any of these values, the values will need to be changed and the Dante server recompiled.

PAC SID Example Screenshots

     

OpenLDAP Example Screenshots

Active Directory Example Screenshots




Copyright © 1998-2024 Inferno Nettverk A/S