LDAP

From Braindump
Jump to navigation Jump to search
Error creating thumbnail: File missing

OSI Protocols

https://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.500

X.500 1984 – 1994

http://sec.cs.kent.ac.uk/x500book/ by D W Chadwick (Weird and Wonderful, Paradise/Cosine)

ASN.1 Type Length Value

X.500 Directory Access Protocol

(famous for X.509v3)

IETF

RFC4510 Technical Specification Road Map

RFC4511 LDAP: Directory Information Models

RFC4512 The Protocol

RFC4513 Authentication Methods and Security Mechanisms

RFC4514 String Representation of Distinguished Names

RFC4515 String Representation of Search Filters

RFC4516 Uniform Resource Locator

RFC4517 Syntaxes and Matching Rules

RFC4518 Internationalized String Preparation

RFC4519 Schema for User Applications

RFC4524 COSINE LDAP/X.500 Schema

Kurt D Zeilenga, LDAP RFC author and creator of OpenLDAP

https://www.openldap.org/

https://www.zytrax.com/books/ldap/

https://ldapwiki.com/wiki/RootDSE

Schema, object tree

namingContext

RootDSE

ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -s base -b "" (objectclass=*)
ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -s base -b "" objectclass="*" namingContexts

objectClass=top

ldapsearch -h hostname -b "" -s base "(objectclass=*)"
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config
ldapmodify -Y EXTERNAL -H ldapi:/// -b cn=config -f loglevel.ldap
ldapmodify -Y EXTERNAL -H ldapi:/// -f loglevel.ldap
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcLogLevel


Centralized O&M access

By default O&M users groups and roles are management on the local nodes. Authentication and access control are in general file based, so the useraccounts and passwords are stored local. Implementing password policies will have to be done on all of the nodes and one user has to be created on all nodes independently.

Using a general directory for o&m user management the accounts are managed centrally. User accounts will be created once and a attached to the userprofile is a list of hosts the user is allowed to access. The password can be managed in a central way and users can be removed from the directory when access should be revoked.

Configuring all nodes to conform to the policies and requirements can be skipped. With an extra effort the nodes can be adapted for central user management by a customer adaptation project

Error creating thumbnail: File missing

LDAP

Both IS and TSP are related to unix / linux systems. Defacto standard for user management is PAM pluggable authentication module. It provides a modular approach to user management. Applications implementing the PAM interface will ask PAM to authenticate users. PAM also allows for modules to act as source of the user credentials. One module is libpam_ldap which connects to the central ldap directory which has all users according to the posixAccount schema as hinted in RFC 2307. This module complements file based user management with ldap clients.

Centralized O&M Access Control

Using LDAP

LDAP

Light weight directory access protocol, as opposed to ITU-T X.500

University of Michigan, OpenLDAP, ASN.1, back-end driver

Description

LDAP defines the access to a database tree. It can be used to store usernames, user-id and passwords for external systems. When a user logs in to an external system which uses an LDAP client the system will retrieve the database tree for that user and based on the password hash decide if the user authenticated using the same user.

ldap server

OpenLDAP               Opensource, driven by Kurt Zeilenga, who published the LDAPv3 RFC

Novell eDirectory      (NDS) As used in the OSS-SLS server

Microsoft AD             Windows Server

Oracle OID                As used in MMC

Sun ONE                   (Sun Java System Directory Server, iPlanet DS)

ApacheDS                (OTP triplesec safehaus)

Name Service Caching

To limit the amount of lookups entries could be cached for a specific amount of time a caching service could be used. For a configurable amount of time the user entry is cached on the local system.

NSSWITCH

Name service switch configures where a posix system should retrieve user information from. By default this is "files". The system retrieves the user information from the /etc/passwd and /etc/group. By using "ldap" the system will retrieve the information from the ldap server.

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap


nis.schema

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount'

       DESC 'Abstraction of an account with POSIX attributes'

       SUP top AUXILIARY

       MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )

       MAY ( userPassword $ loginShell $ gecos $ description ) )

dn: uid=bozo,ou=Users,dc=janmg,dc=com
uid: bozo
uidNumber: 1032
userPassword:: e2NyeXB0fTcwWUMwVkVuZVFrRDI=
host: irmatx2.janmg.com

ns-pwd-policy.schema

objectclass ( 2.16.840.1.113730.3.2.13
        NAME 'passwordPolicy'
        AUXILIARY
        SUP top
        DESC 'Password Policy object class to hold password policy information'
        MAY ( passwordMaxAge $ passwordExp $ passwordMinLength $
              passwordKeepHistory $ passwordInHistory $ passwordChange $
              passwordCheckSyntax $ passwordWarning $ passwordLockout $
              passwordMaxFailure $ passwordUnlock $ passwordLockoutDuration $
              passwordMustChange $ passwordStorageScheme $ passwordMinAge $
              passwordResetFailureCount )
        )


PAM

For services that require authentication and support PAM modules the module libpam_ldap can be used as plugin to use ldap client for authentication. The regular libpam_unix and libpam_cracklib can be used

/etc/pam.d/...
pam_ldap.so
pam_unix.so nullok_secure obscure min=4 max=8 md5 use_first_pass

PAMLDAP
http://www.padl.com/download/

OPTION 1: Host filter

For single services only (e.g. /etc/pam.d/ssh):
  #auth       sufficient   pam_ldap.so
  auth       sufficient   pam_ldap.so filter=|(host=this-host.mydomain.net)(host=\*)
For all services at once (/etc/pam_ldap.conf):
  pam_filter |(host=this-host.mydomain.net)(host=\*)

OPTION 2:

/etc/pam.conf
pam_check_host_attr yes
pam_check_service_attr yes
account required pam_ldap.so

Services

For webservices for apache plugin mod_auth_ldap or mod_ldap can be used

LDAPSharedCacheSize 200000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600

<Location /protected>
  SetHandler ldap-status
  Order deny,allow
  Deny from all
  Allow from operator.com
  AuthLDAPEnabled on
  AuthLDAPURL ldap://127.0.0.1/dc=janmg,dc=com?uid?one
  AuthLDAPAuthoritative on
  Require valid-user
</Location>


Root / Administrator

The local root account should not be retrieved over the network, it should remain in the local files. In case the ldap server is not reachable the basic system login remains functional.

/etc/pam-ldap.conf
pam_filter !(uidNumber=0)


ldap client

The client configuration should say which ldap servers, which base dn tree, which lookup user and password should be used and how long entries should be cached.

LDAP Server Host: 10.0.0.1
DN of Search Base: dc=islief,dc=com
LDAP Version: 3


On these servers a schema that supports users and a mechanism to add users to the trees.

Data object model.  Schema, objectClass,. Attributes. DIT RootDN DN / RDN.

attributetype ( 2.5.4.41 NAME 'name'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )


LDIF

Interchange format

version: 1
dn: cn=john smith,ou=people,dc=islief,dc=com
changetype: modify
objectclass: inetorgperson
objectclass: posixaccount
uidnumber: 1001
gidnumber: 1000
homedirectory: /var/mail/janmg.com/jsmith
objectclass: ourObject


ACL

The server should be configured to give read-rights to the lookup user and write-rights to the administrator user.

access to attr=userpassword
  by self       write
  by anonymous  auth
  by group.exact="cn=itpeople,ou=groups,dc=janmg,dc=com" write
  by *          none


LDAP TLS (LDAPS)

The communication between the client can be protected with TLS, the server can offer a certificate to show it is the real server, but also the client can show a certificate to show it's validity. A X.509 certificate can be self signed or validated by a CA organization. For a CA organization certificate to work an internet connection is required. A more local solution is to have a private CA server.


RFC 4510

RFC 2307 Profiles


KNOWN SHORTCOMINGS


http://linux.die.net/man/8/nscd

Note that the shadow file is specifically not cached. getspnam(3) calls remain uncached as a result. As a result of this behavior there is not possible to change non-nscd user to another non-nscd user via su service when nscd is running.


http://en.wikipedia.org/wiki/Pluggable_Authentication_Modules

Due to limits of the PAM API, it is not possible for a pam module to request a Kerberos service ticket from a Kerberos KDC, allowing the user to utilize the application without re-authenticating. pam_krb5 only fetches ticket granting tickets, which involves prompting the user for credentials and are only used for initial login in an SSO environment. To fetch a service ticket for a particular application, and not prompt the user to enter credentials again, that application must be specifically coded to support Kerberos, as pam_krb5 cannot itself get service tickets.


http://aput.net/~jheiss/krbldap/howto.html

Note that if the service is not directly accepting Kerberos tickets, but rather is taking a username and password and authenticating the user via pam_krb5, you may not need a service principal. For Red Hat's pam_krb5 it is optional. Solaris 8's pam_krb5 doesn't use it, but for Solaris 9's pam_krb5 it is required that you have a host/hostname principal stored in /etc/krb5/krb5.keytab. An additional note, Solaris 9 apparently doesn't support the des3-hmac-sha1:normal Kerberos key type that is one of the two types specified in the kdc.conf I use. Rather than just ignore that key and use the des-cbc-crc:normal key (which Solaris 9 does support), it refused to work. So when creating the host principals for Solaris 9, use commands like the following (which only create des-cbc-crc keys, instead of both like normal).


The only perfectly secure system is the one that offers no interconnection. The are therefore completely unusable, so some form of access should be granted. For telecommunication systems ITU-T [1] and ISO [2] have defined the planes for Signaling, Data and for O&M access. The last plane gives maintenance personnel the opportunity to assess the state of the system and to make changes if necessary.  

Introduction

This document attempts to map the history of centralized user access into the current practice to date. While the mechanisms exist for quiet some time, they are not always the simplest solution in getting. Although experience has shown that managing larger communication networks becomes harder when all systems are treated as single entities.

Business Practice

In a communication production environment, the ownership of responsibilities is a matter of principle. The risk an operator or a vendor is generally minimized. As a consequence systems fulfill requirements of the operator with the smallest amount of adaptations on the vendor systems. Since the most important requirements are put on the end-user experience the operability of  systems are left on the wish list.

Security principles like no shared accounts and the use of connection encryption are in practice sacrificed for usability. In a bad practice user accounts are not locked time.

Historical User management

Posix has defined the interface for system calls on user management, like


uid_t geteuid(void);

struct passwd *getpwuid(uid_t uid);

These are traditionally implemented on the local file system in files like /etc/passwd and /etc/shadow. But this is not the mandatory user repository. In the past NIS has fulfilled the role as network based user management. In popular belief ldap can fulfill the same role as NIS in a more secure way. In RFC 2307 an LDAP approach is documented on using nisSchema containing objects like posixAccount as nameservice

LDAP in practice

In practice the implementation of LDAP based authentication requires an investment in time for understanding and integrating the services. The principle components NSS, LDAP, LDAP schema's, LDAP ACL, PAM, SASL, TLS, PKI, X.509 Certificates. need to be glued together, whereas file based authentication systems work "out of the box". The effort of implementing central user management becomes more worthwhile when the number of users and the number of system increases. The implementation becomes nearly impossible in real life where operators have multiple vendors which have multiple platforms and operators and vendors both use multiple third parties.

Standards like RFC 2307 are needed to reach consensus among multiple parties. They form a common understanding between system vendors without the need for close cooperation. On the field of user authentication many systems exists around the same LDAP principles but a major hurdle in compatibility is the use of different schema's. As a practical example Microsoft's Active Directory is not compatible with Novell eDirectory or the Linux / BSD used OpenLDAP, although they use the same ingredients. Applications and their interfaces running on top of these platforms only make the situation more complex.

Consensus

Reinventing the wheel and claiming IPR is tempting but multiple implementation of the wheel already exists, the main goal of this paper is to reaffirm the best practices so far. The idea is to describe a minimal subset of proposed standards like PAM, Kerberos, SASL and


In addition the goal is to define a superset of objects in the schema proposed in RFC 2307. This superset needs to be a subset of already existing schema's in a way to map the most common.

XSSO PAM - Kerberos   ||  PAM-LDAP login  ||   LDAP Directory Schema

Additional Attention points

Single Sign On, Password policies, Kerberos GSSAPI


TLS, Host filter, role based access, application, redundancy / replication. nss caching. Schema attribute mapping.

2 factor authentication (strong), password hashing (salting) AAA Radius / AAA Diameter

Rewrite

Abstract

Introduction

Business Problem

Best Practice Solution

Technical Components

Minimum GLUE

Optional GLUE

Super GLUE

Conclusion

References

Normative References

RFC 4510 " Lightweight Directory Access Protocol"

http://tools.ietf.org/html/rfc2307


RFC 2307 "An Approach for Using LDAP as a Network Information Service"

http://tools.ietf.org/html/rfc2307


Microsoft MSDN, "Active Directory Schema"

http://msdn.microsoft.com/en-us/library/ms675085(VS.85).aspx


X/Open XSSO-PAM

http://www.opengroup.org/pubs/catalog/p702.htm

http://www.opengroup.org/onlinepubs/8329799/

Informative References

Kerberos " Why is Kerberos a credible security solution?"

http://www.kerberos.org/software/whykerberos.pdf


PAM Pluggable Authentication Modules

RFC 86.0


XSSO

http://mirror.sweon.net/madchat/coding/unix/xsso.pdf


LDAP RFC

http://tools.ietf.org/html/rfc4510

LDAP for NIS

http://tools.ietf.org/html/rfc2307

LDAP for rocket scientists

http://www.zytrax.com/books/ldap/

MAX

http://home.subnet.at/~max/ldap/

Active Directory

autorid / rid => rfc2307 unix profile in ldap


LDAP Authentication

With the LDAP bind operation, or password hash comparison


Active Directory (Microsoft Schema)

https://learn.microsoft.com/en-us/openspecs/windows_protocols/MS-WINPROTLP/e36c976a-6263-42a8-b119-7a3cc41ddd2a

Microsoft Windows 2000, (and subsequent Server 2003, 2008, 2012, 2016, 2019, 2022, 2025)

https://aka.ms/aaddev

Azure AD Authentication Fundamentals

echo %logonserver%

nslookup -t srv _ldap._tcp.dc._msdcs.islief.com

nslookup _msdcs.islief.com

nltest /dclist:ISLIEF

Import-Module ActiveDirectory

(Get-ADDomainController -DomainName islief.com -Discover -NextClosestSite).HostName

gpresult /v