Windows ldap bind user

Introduction

This document describes the necessary architecture in order to properly enable ldap authentication and group authorization on a datapower. The first section considers general architecture, limitations on the solution, and caveats to progress. Finally, actual build configuration is covered as well as how to implement ‘secure’ ldap instead of just ldap.

General Architecture

This document assumes that you have setup a proper Active Directory domain using windows server 2012R2. Other versions of windows may work, but were not tested with this configuration. Also note that if secure LDAP is desired, that the domain server MUST be configured with certificate services, and that the signing cert’s common name MUST match its host name in order to work.

Directory Setup

In order for the datapower to easily lookup group memberships, it is required to setup a new OU, called ‘groups’ at the top of the active directory tree. This makes it more efficient to lookup usernames, as the system doesn’t have to peruse the entire directory tree. For further segregation by environment the figure below delineates a typical structure:

The TLD (top level domain) is the domain, followed by the “OU” of groups, which has two Common Names, (groups actually), followed by further divisions into prod, dev, and Qa environments which can have separate permissions (with the appropriate modifications of the configuration files as noted later in this documents). Breaking things down this way enables fairly complex rule possibilities, while still maintaining a relatively simple structure.

Additionally, it is important to note that case is VITAL when referencing items within the directory. Windows seems to return UPPERCASE attributes, yet seems to expect ‘lower case’ when sending things.

Bind Credentials to perform Searches

Windows server 2012 and others do not allow for anonymous binds for security reasons. It is strongly recommended that anonymous binding NOT be enabled, but rather to setup a low privilege user, with a sufficiently complex password, to allow binding to the directory.

It is imperative that the account NOT be set to expire, since this would cause the datapower devices to fail ALL users until the credential was updated on ALL datapowers involved in central authentication. For the purposes of this document, it is assumed that a standard ‘domain’ level user will be created, and will be named ‘datapower’.

It is also important to NOT fill out ANY fields such as ‘first name’ last name, etc., or the processes described in here will FAIL, since the bind strings will use the first name, middle initial, and last name as a LOGIN name! ONLY when these fields are left blank will this solution work.

Secure vs Insecure LDAP for initial configuration

While the initial temptation to use ‘secure’ ldap may be strong, it is advised against until a configuration has been fully tested. Below are the reasons why:

1. Secure ldap prevents easy debugging of packet traces
2. Secure ldap can have issues of its own, such as crypto mismatch, cert issues, that can make it confusing to find out if your configuration is valid
3. Secure LDAP also requires additional configuration on datapower side, that can cause logins to fail, which might be falsely attributed to a defective rbm file.

It is recommended that secure ldap ONLY be enabled after a configuration has been fully vetted and tested.

Authorization File / Group Mapping

The primary method for enabling remote login / group assignments is via an xml file called the ‘rbm’ or ‘role based management’ file. This file is created, edited, and then uploaded to the datapower, where it enforces group and user authorizations (for the purposes of this document, ONLY group memberships are used).

It is VITAL that there always be a fallback account on the local machine, in case remote system are prevented from logging in. Failure to enable ‘local user bypass’ will cause the machine to be locked out, and may possibly require an RMA from IBM, or a command line reset of permissions. It is recommended that ‘user timeouts’ be disabled, and a console be logged into with the ‘admin’ account, should remediation become necessary.

It is rather confusing, but all local user groups are IGNORED once the custom rbm is uploaded, and is only valid for LOCAL user accounts. There is NO correlation between local groups and AD(active directory) groups!

Caveats

There are many peculiarities of setting up LDAP on a datapower. Beware the following:

• The “Bind” CN used for searching the ldap directory should have NO information filled out in ANY of its fields or the solution here will not work. Windows will use “Thomas J Munn” instead of ‘tmunn’ as a login if there is First, Last, or Middle initial provided. It also will use ‘spaces’ and ALL characters listed in the user attribute fields.
• For returning the actual ‘username’ that everyone expects, the ‘              sAMAccountName’ attribute (without the backticks!). The CASE IS CRITICAL on this.
• This solution can ONLY work for users with 1 group. Multiple group memberships within the same OU (e.g. OU=groups), will FAIL. For further subdivision, see section on segregating the directory by OU for more complex groupings.
• The CSR (signing authority) needs to match the DNS name of the server presenting itself as the LDAP server. If they don’t match, SSL will fail
• A dedicated ‘datapower’ user is recommended, because binding to an AD directory anonymously is not recommended.

Configuration

In this section, basic configuration of the datapower is covered. For clarity, the CLI will be used, and only where such is not possible will the GUI be used. In such cases, screen shots will be provided, with textual descriptions below them. Things to be typed in will use the style below

Command 1 parameter

Additionally, parameters that need to be change will be in italics. This might include things like the domain name, and appropriate suffixes.

Basic LDAP Authentication and Authorization sections

The sections below detail the necessary changes to make the datapower use LDAP for authorization and group membership information.

CLI Stanzas- Ldap Search Parameters

Note that the three groups as noted in the ‘filter suffix’ means that you can ONLY be a member of the ‘admin, readonly, or sysadmin’ groups. More groups can be added assuming parenthesis are balanced properly.

RBM CLI Parameters

The CLI parameters below assume are for reference only, it is advised to use the “GUI” to work here. Directly referencing the ‘xml’ file without using the GUI can be dangerous, so it is encouraged to use GUI.

A couple of lines bear some explanation. The ‘au-server-host’ is the ldap server, the ‘bind dn’ is the ‘common name’ of the userid doing the bind to the directory.

‘fallback-login local’ means if you don’t do things right, you can get back into the datapower. Please note that the RBMLDAP-ibm.xml should be uploaded and added via the GUI tool. This section is mostly for reference when doing the ‘gui’ portion of the configuration.

Картинка с сайта: symgryph.wordpress.com

RBM Settings Dialogue

RBM Settings dialogue

• Go to ‘administration, rbm settings. Ensure things are ‘enabled’ and that RBM on cli and restrict admin login are ‘off’
• Go to the ‘authentication’ tab, since most of this was done in the CLI, refer to CLI section for actual parameters to type in. CASE IS CRITICAL.  The picture on the next page details the necessary settings to choose.

The next section details changes necessary to the authentication tab:

Картинка с сайта: symgryph.wordpress.com

Necessary settings for authentication. See CLI section for proper values!

Credentials (authorization) process from GUI:

Картинка с сайта: symgryph.wordpress.com

RBM Settings Dialogue

RBM Upload Process

The section following this page details how to setup the RBM info file, and upload it to the server. First is the file itself. It is described in the following pages. Second is to have the datapower ‘process’ it to ensure that there are no errors, and final is to ‘accept’ the profile change to apply the Role Based Management mapping file. This file contains the groups in ldap and changes them to datapower permissions. CASE IS CRITICAL, SYNTAX IS CRITICAL. It is recommended that if frequent edits are necessary to have a program that will properly format the file. Human editing beyond initial configuration is strongly discouraged. Also if you have any errors, ALL ACCESS to device is lost, save local accounts!

RBMLDAP-ibm.xml listing

Some explanations.

The line ‘aaa:InputCredential” is the ldap bind that will return the ‘admin’ group of which people have been made members of. As noted earlier, it would be the ou created in the earlier section. Obviously the DC=blah, DC=com needs to be changed to match your domain suffix.  Names of groups are CASE SENSITIVE. Separate access within a group can be added by using appropriate syntax and a ‘space’ between the two permission statements. MULTIPLE GROUPS WILL NOT MATCH!!!

Having built this file, the subsequent screens will show how to get this working. Again, prior to doing this CREATE A BACKUP ADMIN USER.

It is recommended that an XML syntax checker be applied to any file being edited, such as Notepad ++ with the XML syntax checker.

GUI Upload Process for RBMINFO.XML file
From the ‘+’ on the previous page diagram, choose ‘new rbm file’

Картинка с сайта: symgryph.wordpress.com

Choose ‘upload’, and using naming convention as noted, choose file, and continue.

Картинка с сайта: symgryph.wordpress.com

RBM upload Step 2

choose the ‘next’ button

Картинка с сайта: symgryph.wordpress.com

Choose the “next” button again

Картинка с сайта: symgryph.wordpress.com

Choose ‘next’

Картинка с сайта: symgryph.wordpress.com

Your final screen should look like the above screen.

The final step is to commit. Be sure to ‘overwrite’ existing file, or the system will force you to create a new file and things will FAIL. Also note that taking too long will cause the system to ‘time out’ and lose all of your work!

Картинка с сайта: symgryph.wordpress.com

Final Committ Dialogue

Choose ‘commit’ and then ‘save’ and apply. This concludes the configuration of the RBM. If everything is working, you should have an authenticating datapower.

Troubleshooting Techniques

This section details how to troubleshoot problems. Frequently, the system will either have case problems, bind issues, or certificate issues. Packet captures and dissection are necessary in order to properly diagnose issues.

Here are some tools that can help with LDAP issues:

·       Wireshark: For processing packet captures, or capturing on the ‘server’ end. Datapower can also capture, but not process, packets.

·       Enable CLI packet capture on datapower:

The second line is not to be typed in until debug is done. Packet captures can be retrieved by going to the file manager, and downloading them and dissecting with datapower.

·       Format check XML with Notepad++ and XML module: this enables XML syntax checking and helps with errors in XML.

·       CASE matters! It can vary widely depending on which version of windows, or LDAP server you are using. ANY errors in case will prevent things from working

·       Separate configuration from Secure LDAP config phases. This document does not detail how to enable secure LDAP, but only describes a basic LDAP configuration. LDAP configuration with ssl requires advanced knowledge of certs/ssl and is beyond the scope of this document.

·       Finally, if help beyond this is required, CALL IBM. They helped me configure this.

·       LDAP Browser: Jexplorer works nicely. Good way to test passwords/uids. Also helps find CN’s etc.

U       Use Putty for ssh connections or even better use SecureCRT!

YTThis document in ‘word’ format:

Word Document of this posting

This describes how to configure SSSD to authenticate with a Windows Server
using id_provider=ldap.

It is recommended to use the AD provider when connecting to an AD server,
for performance and ease of use reasons. Please see Integrating with a Windows server using the AD provider for
a reference. There are two reasons where you might still want to use the
LDAP provider, though. One is if you are using a very old SSSD version,
the other reason is if you cannot or do not want join your GNU/Linux clients
to the AD domain.

[global]
workgroup = EXAMPLE
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
log file = /var/log/samba/%m.log
password server = AD.EXAMPLE.COM
realm = EXAMPLE.COM
security = ads

# net ads join createupn="nfs/client.ad.example.com@AD.EXAMPLE.COM" -U Administrator

[logging]
default = FILE:/var/log/krb5libs.log

[libdefaults]
default_realm = AD.EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
rdns = false
forwardable = yes

# You may also want either of:
# allow_weak_crypto = true
# default_tkt_enctypes = arcfour-hmac

[realms]
# Define only if DNS lookups are not working
# AD.EXAMPLE.COM = {
#  kdc = server.ad.example.com
#  admin_server = server.ad.example.com
# }

[domain_realm]
# Define only if DNS lookups are not working
# .ad.example.com = AD.EXAMPLE.COM
# ad.example.com = AD.EXAMPLE.COM

# klist -ke
# kinit -k CLIENT$@AD.EXAMPLE.COM

# kinit -k -t /etc/krb5.keytab nfs/client.ad.example.com@AD.EXAMPLE.COM

# /usr/bin/ldapsearch -H ldap://server.ad.example.com/ -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))"

[sssd]
domains = ad.example.com
services = nss, pam

[nss]

[pam]

[domain/ad.example.com]
# Unless you know you need referrals, turn them off
ldap_referrals = false
# Uncomment if you need offline logins
# cache_credentials = true
enumerate = false

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

# Uncomment if service discovery is not working
#ldap_uri = ldap://server.ad.example.com/

# Comment out if not using SASL/GSSAPI to bind
ldap_sasl_mech = GSSAPI
# Uncomment and adjust if the default principal host/fqdn@REALM is not available
#ldap_sasl_authid = nfs/client.ad.example.com@AD.EXAMPLE.COM

# Define these only if anonymous binds are not allowed and no keytab is available
# Enabling use_start_tls is very important, otherwise the bind password is transmitted
# over the network in the clear
#ldap_id_use_start_tls = True
#ldap_default_bind_dn = CN=binduser,OU=user accounts,DC=ad,DC=example,DC=com
#ldap_default_authtok_type = password
#ldap_default_authtok = bindpass

ldap_schema = rfc2307bis

ldap_user_search_base = ou=user accounts,dc=ad,dc=example,dc=com
ldap_user_object_class = user

ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName

ldap_group_search_base = ou=groups,dc=ad,dc=example,dc=com
ldap_group_object_class = group

ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true

# Uncomment if dns discovery of your AD servers isn't working.
#krb5_server = server.ad.example.com
krb5_realm = AD.EXAMPLE.COM

# Probably required with sssd 1.8.x and newer
krb5_canonicalize = false

# Perhaps you need to redirect to certain attributes?
# ldap_user_object_class = user
# ldap_user_name = sAMAccountName
# ldap_user_uid_number = msSFU30UidNumber
# ldap_user_gid_number = msSFU30GidNumber
# ldap_user_gecos = displayName
# ldap_user_home_directory = msSFU30HomeDirectory
# ldap_user_shell = msSFU30LoginShell
# ldap_user_principal = userPrincipalName
# ldap_group_object_class = group
# ldap_group_name = cn
# ldap_group_gid_number = msSFU30GidNumber

# authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

#
# /etc/nsswitch.conf
#

passwd:         files sss
shadow:         files sss
group:          files sss

hosts:          files dns

bootparams:     files

ethers:         files
netmasks:       files
networks:       files
protocols:      files
rpc:            files
services:       files sss

netgroup:       files sss

publickey:      files

automount:      files sss
aliases:        files

auth         sufficient    pam_sss.so use_first_pass

account      [default=bad success=ok user_unknown=ignore] pam_sss.so

password     sufficient    pam_sss.so use_authtok

session      optional      pam_mkhomedir.so

session      optional      pam_sss.so

service sssd stop; rm -f /var/lib/sss/db/*; service sssd start

LDAP and why it is used

Lightweight Directory Access Process (LDAP) serves as a user authentication mechanism tailored for directory services. This protocol is commonly employed by applications to retrieve resource data such as user profiles and various system elements. LDAP enables the identification of a client’s attributes with servers such as Active Directory, OpenLDAP, and Open DJ. Introduced in 1993, LDAP version 3 has been the Internet standard for directory services since 1997. LDAP configuration is important for security hardening and compliance.

LDAP is frequently used as a centralized repository for storing user credentials, such as usernames and passwords. This centralized storage mechanism enables multiple applications and services to interface with the LDAP server for user authentication purposes.

Картинка с сайта: calcomsoftware.com

By leveraging LDAP, organizations can establish a unified authentication system, streamlining access management across various platforms and services. This approach enhances security by centralizing user credentials management, simplifying administrative tasks, and ensuring consistent authentication procedures across the network. Additionally, LDAP’s flexibility allows for seamless integration with diverse systems, contributing to its widespread adoption as a fundamental component of identity management solutions.

Картинка с сайта: calcomsoftware.com

What is LDAP authentication (LDAP simple bind)?

The most common method for authenticating LDAP clients is through simple bind authentication. In this process, the client either binds anonymously, using an empty bind Distinguished Name (DN) or provides a DN along with a password. The Directory Proxy Server binds to a data source to verify these credentials and authenticate the client.

LDAP authentication can be illustrated effectively with an example involving an employee attempting to access their organization’s network. Since the most common action performed in such scenarios is logging into the network, the predominant function utilized is ‘read’. The LDAP protocol is specifically engineered to efficiently manage a large volume of read operations like these.

There are two main components in the LDAP authentication mechanism:

1. LDAP Directory Server Setup – where the employee profile details are stored (username and password in this case).
2. LDAP client – the employee’s computer. It should have an LDAP client option setup. If the employee is going to authenticate through a web application, then the server hosting the application must be configured with an LDAP client.

LDAP authentication process has two stages:

1. Identifying the user’s directory attribute – The user entry is identified by its DN, which is the path to its details. In the first stage of the authentication, the user must obtain its DN and password. The user name usually requested in the login form is used to find the user’s DN. A function called DN Resolution takes the user name (or email in some cases) and runs a search to find all the user entries to find his DN. Once the correct user DN is resolved, the next step is to validate the user’s password.
2. Password validation – The user’s password is checked by a command called ‘bind’. The LDAP directory server receives a request to authenticate the user bypassing its DN and password. If the credentials are correct, the directory server returns success, and the connection is established.

2 Security settings that do not have any impact on LDAP simple bind are:

• Ensure ‘Network security: LDAP client signing requirements’ is set to ‘Negotiate signing’ or higher

• Ensure ‘Domain controller: LDAP server signing requirements’ is set to ‘Require signing’

What is LDAP channel binding?

Security setting ‘Ensure ‘Domain controller: LDAP server channel binding token requirements’ is set to ‘Always’ discusses channel binding.

This configuration option determines whether the LDAP server (Domain Controller) mandates the verification of Channel Binding Tokens (CBT) included in LDAP bind requests transmitted over SSL/TLS, commonly referred to as LDAPS.

The recommended state for this setting is: Always.

Mandating Channel Binding Tokens (CBT) serves as a preventive measure against attackers attempting to exploit captured authentication credentials (such as OAuth tokens or session identifiers) by deterring their reuse in separate TLS sessions. Additionally, this practice strengthens defenses against “man-in-the-middle” attacks when employing LDAP authentication over SSL/TLS (LDAPS).

When first deploying this setting, you may initially want to only set it to the alternate setting of When supported (instead of Always) on all Domain Controllers. This alternate, interim setting enables support for LDAP client channel binding but does not require it. Then set one DC that is not currently being targeted by LDAP clients to Always, and test each of the critical LDAP clients against that DC (and remediating as necessary), before deploying Always to the rest of the DCs.

By automated configuration hardening of this setting organizations can guarantee that the desired configurations are uniformly applied across all Domain Controllers. It eliminates the potential for human error that may occur with manual configuration, reducing the risk of misconfigurations that could compromise security. Automated configuration hardening enables organizations to swiftly implement changes and updates across their infrastructure, enhancing overall agility and responsiveness. Automated testing mechanisms can be integrated to validate configurations and assess their impact on critical LDAP clients, ensuring that any necessary adjustments are promptly identified and remediated.

Harden Cipher Suites for Robust TLS/SSL Encryption

What is LDAP signing?

LDAP Signing is a security feature that ensures the integrity of communications between LDAP clients and domain controllers. LDAP signing is a feature of the Simple Authentication and Security Layer (SASL). SASL provides several mechanisms to increase the security of an LDAP connection, including user authentication, anti-tampering (message signing), and confidentiality (encryption). SASL is a communication layer that operates within LDAP on the default AD data ports (TCP port 389 and TCP port 3268)

Domain Controller: LDAP Server Signing Requirements

How to Enable LDAP Signing Configuration

For enabling LDAP signing in the server and the client you can either use Group Policy Object (GPO) or a registry key.

How to configure a server LDAP signing GPO:

1. Go to ‘Default Domain Controller Policy’ > ‘Computer Configuration’ > ‘Policies’ > ‘Windows Settings’ > ‘Security Settings’ > ‘Local Policies’, and then select ‘Security Options’.
2. Right-click ‘Domain controller: LDAP server signing requirements’, and select Properties.
3. Enable ‘Define this policy setting’, select ‘Require signing’ in the ‘Define this policy setting list’, and then select OK.

How to configure LDAP Singing at a client’s local computer policy:

1. Go to ‘Local Computer Policy’ > ‘Computer Configuration’ > ‘Policies’ > ‘Windows Settings’ > ‘Security Settings’ > ‘Local Policies’ and select ‘Security Options’.

1. Right-click ‘Network security: LDAP client signing requirements’ and select ‘Properties’.
2. In the dialog box, select ‘Require signing’ in the list, and then select OK.

How to configure a server LDAP signing using a registry key:

Note! We recommend backing up your registry before pushing any changes, as mistakes can have devastating results.

You need to create an LDAPServerIntegrity registry entry of the REG_DWORD type under the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<InstanceName>\Parameters

*instance name= the name of the AD LDS you want to configure.

LDAP Vulnerabilities Affecting Domain Controllers

CVE-2023-21676: A security flaw within LDAP poses a risk of enabling a remote code execution by an authenticated attacker on Windows Server installations functioning as Domain Controllers. This vulnerability presents a low-complexity attack vector accessible over the network.

CVE-2023-21557: is a vulnerability in LDAP that could allow an unauthenticated attacker could send a specially crafted request to a vulnerable LDAP server. Successful exploitation could result in bypassing a buffer length check which could be leveraged to achieve information leak.

Картинка с сайта: calcomsoftware.com

To improve the security of your directory server you can implement several configuration rules. These rules are best practices, and recommended also by the Center for Internet Security (CIS):

1. Ensure ‘LDAP server signing requirements’ is set to ‘Require signing’. – This policy setting will make clients use data signing.
2. Ensure ‘Extended Protection for LDAP Authentication (Domain Controllers only)’ is set to ‘Enabled: Enabled (recommended: always) – this setting controls LDAP authentication over SSL/TLS.
3. Ensure ‘Network security: LDAP client signing requirements’ is set to ‘Negotiate signing’ or higher – this policy sets the level of signing requested by the client who issues LDAP request.

LDAP Configuration and the MITRE ATT&CK Framework

Configuring LDAP for optimal security is a recommended best practice by the MITRE ATT&CK framework stating few techniques and mitigations

T1087– Adversaries may attempt to get a listing of domain accounts. This information can help adversaries determine which domain accounts exist to aid in follow-on behavior such as targeting specific accounts which possess particular privileges. Commands such as net user /domain and net group /domain of the Net utility, dscacheutil -q groupon macOS, and ldapsearch on Linux can list domain users and groups. PowerShell cmdlets including Get-ADUser and Get-ADGroupMember may enumerate members of Active Directory groups.

T1482- MITRE ATTACK framework clasify LDAP configuration settings under the technique- Domain Trust Discovery– , stating that Adversaries may attempt to gather information on domain trust relationships that may be used to identify lateral movement opportunities in Windows  multi-domain/forest environments. Domain trusts can be enumerated using LDAP. the Windows utility Nltest is known to be used by adversaries to enumerate domain trusts.

Changing configurations as part of server hardening is critical for security but may cause severe damage. We strongly recommend using automation to prevent any possible outages in your production. The alternative for automation is using manual tools (GPO for example), testing the impact of the change in a lab environment, and hoping you covered all possible scenarios. By using automation in hardening, you will not need to test. You will get a full impact report to help you make the best decision for both security and operations.