www.novell.com

Using ACLs in LDAP: Creating a Secure Novell eDirectory™ Infrastructure

Using ACLs in LDAP: Creating a Secure Novell eDirectory™ Infrastructure

Mike RichichiAssistant Director of Academic TechnologyDrew UniversityDeveloperNet Volunteer Sysopmrichich@drew.edu

Deployed Versions Novell eDirectory™ and Novell Directory Services® (NDS)

Product Version Build Version

Platforms

NetWare 5.1 SP4 (NDS 7) DS.nlm v7.57 NetWare 5.1

NetWare 5.1 SP 4 (NDS 8) DS.nlm v8.79 NetWare 5.1

eDirectory 8 DS.nlm & DS.dlm v8.79

NetWare 5.0,Win NT/2K

eDirectory 8.5.x DS v85.23 NetWare 5.x,Win,Solaris

NetWare 6 (eDirectory 8.6) DS.nlm v10110.20 NetWare 6

eDirectory 8.6.1 DS v10210.43 NW 5.1,NW 6,Win,Solaris,Linux

NetWare 6 SP1 (eDirectory 8.6.2)

DS.nlm v10310.17 NetWare 6

eDirectory 8.6.2 DS v103xx.xx NW 5.1,NW 6,Win,Solaris,Linux

eDirectory 8.7 DS v10410.xx NW 5.1,NW 6,Win,Solaris,Linux,AIX

Differences between eDirectory and NDS®

NetWare 6

NetWare

NDS eDirectory

NOS directory focused on managing NetWare® servers

A cross-platform, scalable, standards-based directory

used for managing identities that span all aspects of the network—eDirectory

is the foundation for eBusiness

NetWare 5

What We’ll Cover

• Review of eDirectory access control Inheritance Security principals Default ACLs Determining effective rights

• Review of LDAP (very brief)• How ACLs are exposed via LDAP

Text representation LDAP extension for getting effective rights

What We’ll Cover (cont.)

• Code examples C API LDIF perl-ldap

• Tying it all together How rights affect your code and what LDAP does Organizing your tree and rights effectively Gotchas

• Concluding thoughts

Important Compatibility Note

• All of this talk is based on eDirectory 8.5 or later, for any supported OS

• C SDK examples run on Novell NetWare®, Win32, Solaris, Linux (currently)

• Perl code can be run on nearly any system that supports perl-ldap

Access Control in eDirectory

• eDirectory has powerful access control capabilities, especially compared to other LDAP directories

• Every object can be given rights to every other object

• Rights flow down the tree by default, can be blocked by inherited rights filters (IRFs)

• Rights are granular (read, write, create) and can apply to specific attributes of an object

• Access control rights are enforced in the deepest, darkest corners of eDirectory, and are a fundamental part of eDirectory operation

Security Principals

• Every object in eDirectory is a security principal Can be used in an ACL entry

• It may not always be meaningful or what you think it means

Application can be given rights to a user—what?

• Rights are generally given to objects that actually log in to an eDirectory tree, container objects, or objects that objects are security-equivalent to

I.e., objects with a key pair that log in to servers, container objects whose leaves inherit their security equivalences, or groups and organizational roles for whom users are security- equivalent to when in the group or occupant of the role

Organizational Units are security principals

Security Equivalences

• securityEquals is an attribute of an object whose values are other objects

• The objects listed in the attribute have their access control rights added to the object they’re listed in

• There are implicit equivalences for all container objects of an object

• Equivalences are automatically updated with group membership and organizational role occupation

• Security equivalences can be explicitly defined as well

securityEquals is a normal attribute on a user object

Dynamic Groups

• Available with eDirectory 8.6.1 and later Group is defined as an LDAP search filter

statement Users are not explicitly security equivalent to a

dynamic group Special ACL rights mask identifies ACLs that

reference dynamic groups, thus triggering the search when object is accessed

TID 10067369 is your friend here

Basic eDirectory Rights

• Entry rights Apply to the “object itself” Supervisor, Browse, Create, Delete, Rename Supervisor to the entry implies supervisor to all

attributes

• Property rights Apply to specific attributes of the object Supervisor, Compare, Read, Write, Add Self

Effective Rights Calculations

• Rights are calculated by checking granted rights at each level of the tree with the user’s security equivalences (explicit and inherited)

• If rights are assigned to the same object at two levels of tree, the one “closest” to the user is applied

But effective rights granted through container objects or other security equivalences are still added to total rights ([Public] rights, for instance)

How Are ACLs Applied?

• ACLs are assigned via management interfaces

Novell ConsoleOne®

LDAP etc.

• Also are assigned upon object creation as defined by the default ACL attribute of the object class itself

What Is this Default ACL of Which You Speak?

• Default ACL is a property of an object class, defined in the schema, that allows for the automatic assignment of ACLs on object creation

• It is not exposed via LDAP, but of course the ACLs assigned are enforced by eDirectory over LDAP

• Modifying default ACL cannot be done via LDAP or usual tools

ACLs on the object can be removed or modified after object creation, however

The Default ACL for User (inetOrgPerson)

• An object of class inetOrgPerson in LDAP will be created with the following access rights

[Public] read access to messageServer and groupMembership [Root] read access to networkAddress Self read/write to loginScript and printJobConfiguration, and

read to all other attributes

• Why are these set? I don’t know Probably legacy applications/tree behavior—I’m checking it out

• This may not be what you want Are what groups your users are in private information?

Do you want them mucking about with their own login scripts?

Standard ACLs on a New Tree

• [Public] has entry browse rights to the entire tree ([Root)

• Cn=admin,o=Organization has supervisor rights on all entries from [Root] down

Watch Your Apps

• Other apps (including Novell apps) may change default rights assignments on your tree

• There may be things you want hidden that are not any longer

Check Your Default Rights

• Your organization probably has policies on what personal data can be shared inside and out of the organization

Universities: FERPA (Family Educational Rights and Privacy Act) Discrimination/confidentiality concerns

• There can be good reasons to modify default rights in some environments, but it can make things more difficult

If you remove [Public] entry rights, people have to know who they are, and people cannot browse to other users for rights assignments

Changing browse rights to [Root] from [Public] to [Root] means only authenticated users can browse all objects in the tree

Changing default rights on directory information may make eDirectory less useful as a general directory• But more useful as an institutional tool

What’s the Difference Between [Public] and [Root], Anyway?

• [Public] is a syntax for an unauthenticated user

• [Root] is any user (authenticated) in the tree

• [Public] and [Root] are not ‘real’ objects, but can be assigned in ACLs

The X-NDS_PUBLIC_READ flag

• Some attributes in eDirectory are defined as public read

• These attributes are visible regardless of any ACL settings on the object itself

• Notably, objectClass Which sort of makes sense, but probably a good

idea to not name attributes “topSecretDecoderRingKey” or something like that

Brief Introduction to LDAP

• LDAP is an Internet standard (v3: RFCs 2251-2256) that defines an access methodology to a directory service

• It defines authentication, syntax, and operations, as well as methods for extending the basic functionality of the directory

• eDirectory is fully LDAP v3 compliant (all MUST statements in protocol description, many MAY)

LDAP SDKs

• Programmatic interfaces to the LDAP protocols

• If the SDK speaks pure LDAP, then any SDK can be used to speak to any LDAP server

• Novell makes SDKs for C and Java• Other vendors make SDKs for other

languages• Open source implementations in OpenLDAP

(C), Perl, Python, PHP…

LDAP Operations

• Bind—authenticate to the directory• Unbind—disconnect • Search—basic information finding operation• Modify—modify content of a (add/remove

attributes)• Add—add an new object to the directory• Delete—remove an object from the directory• Modify DN—change an object’s distinguished name• Compare—test a value of an attribute • Abandon—finish a connection abruptly• Plus extended operations (defined by schema)

LDAP View of the Tree

• The tree consists of objects, attributes, values, and schema

Objects: basic entries in directory, identified by their distinguished name

Attributes: field names of data in an object Values: specific pieces of data in attributes Schema: the rules that define the types of

objects, which objects contain other objects, which attributes a type of object has, the format of attribute values

How ACLs Are Manipulated in LDAP

• ACL is simply an attribute of an object Is part of the top object class, so all

objects have an ACL ACLs are multipart attributes LDAP displays ACLs in a tagged text

representation

Default ACL of inetOrgPerson (User)

dn: cn=jsmallberries,ou=propulsion,o=yoyodyneACL: 2#subtree#cn=jsmallberries,ou=propulsion,o=yoyodyne#[All

Attributes Rights]ACL:

6#entry#cn=jsmallberries,ou=propulsion,o=yoyodyne#loginScript

ACL: 2#entry#[Public]#messageServerACL: 2#entry#[Root]#groupMembershipACL:

6#entry#cn=jsmallberries,ou=propulsion,o=yoyodyne#printJobConfiguration

ACL: 2#entry#[Root]#networkAddressACL: 2#entry#[Public]#groupMembershipACL: 1#entry#[Public]#cn

Parts of an LDAP ACL

ndsAcl = privileges "#" scope "#" subjectname "#" protectedattrname

• privileges: bitmask describing rights assigned • scope: either entry or subtree

entry: only for actual object subtree: for the object and its subordinates

• subjectname: DN of object who is getting rights (security principal)

• protecteattrname: attributes protected by ACL [All Attributes Rights]: every attribute of object (and its

subordinates if scope is subtree)

[Entry Rights]: rights to the object itself Specific attribute: LDAP name of eDirectory attribute

Rights Mask

Value Attributes [Entry Rights]

1 Compare Attributes Browse Entry

2 Read Attributes Add Entry

4 Write, Add, Delete Attrs

Delete Entry

8 Add/Delete Self Rename Entry

16 (none) Supervisory

32 Supervisory (none)

536870912

Dynamic ACL Dynamic ACL

More ACL Examples

• 47#entry#cn=admin,o=yoyodyne#mail 47=32+8+4+2+1= Supervisor; Add/Delete

Self; Write, Add, Delete Attrs; Read; Compare

• 2#subtree#ou=propulsion,o=yoyodyne#[All Attributes Rights]

2=2=Read Attributes

• Impress your friends—memorize or quickly compute LDAP ACL bitmasks

Adding or Removing ACLs

• ACLs are just regular attributes on the object and can be added, deleted, or modified like any other attribute

• There are no special calls or routines needed to modify ACLs in LDAP, and any LDAP client or SDK that can read and write attributes can manage eDirectory ACLs

Of course, you need rights to modify the attribute—either supervisory rights to the object or Write rights to the ACL property of the object

Write right to the ACL property of an object is effectively full access to the object itself

How Rights Affect LDAP Search Operations

• Searches are done as the authenticated LDAP user (or the defined LDAP proxy user if an anonymous bind)

All eDirectory access rights are enforced

• Search will only return results if user has rights to read both the attributes and objects being searched for

• Search calls will never fail based on lack of rights to an object or an attribute—they simply return no objects or attributes

LDAP Rights Evaluation

• You will not see attributes that you don’t have rights to, so it is like they don’t exist to you

You do know what is possibly there by examining the schema, however

• This is both a curse and a blessing Make sure you write your application to deal with

the fact that different results may be returned based on who is logging in (including things like number of entries and attributes, and getting no attributes returned, or that you were going to use an attribute for something really cool and now it’s not there…)

A Note about the LDAP Proxy User

• The LDAP proxy user is a normal user account• It must not have a password assigned to it• People can log in to the tree as LDAP_Proxy

Hide or rename your LDAP_Proxy user Restrict it to log in only from LDAP servers Enhancement request: Assign password to LDAP_Proxy,

require LDAP server to use it for anonymous binds (store it in the LDAP Server or LDAP Group object)

• Since anonymous binds are functionally equivalent to [Public] anyway, consider not using an LDAP proxy user and modifying [Public]’s rights as appropriate

Hey, This Is a Developer Lecture— When Are We Going to See Some Code?

• NDK—modifyACL.c

• We’ll see code is parsing the ACL string for us to make it more human-readable

• Notice how SDK builds modify statements

LDAP Extension for Get Effective Privileges

• An LDAP extension is an additional operation supported by a server to provide additional functionality

• LDAP extensions are a part of the LDAP v3 standard

More Sample Code

• Extensions/getpriv.c

• The SDK hides things like the extension OID, checking the root DSE to see if the schema extension exists, etc.

Using LDIF to Manage ACLs

dn: cn=jsmallberries,ou=propulsion,o=yoyodyneuid: jsmallberriesgivenName: JohnfullName: John SmallberriesLanguage: ENGLISHsn: SmallberriesobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: personobjectClass: ndsLoginPropertiesobjectClass: topcn: jsmallberries

LDIF of a User (cont.)

ACL: 2#subtree#cn=jsmallberries,ou=propulsion,o=yoyodyne#[All Attributes Rights]

ACL: 6#entry#cn=jsmallberries,ou=propulsion,o=yoyodyne#loginScript

ACL: 2#entry#[Public]#messageServerACL: 2#entry#[Root]#groupMembershipACL:

6#entry#cn=jsmallberries,ou=propulsion,o=yoyodyne#printJobConfiguration

ACL: 2#entry#[Root]#networkAddressACL: 2#entry#[Public]#groupMembershipACL: 1#entry#[Public]#cnACL: 7#entry#cn=admin,o=yoyodyne#[Entry Rights]

Modifications in LDIF

version: 3dn: cn=jsmallberries,ou=propulsion,o=yoyodynechangetype: modifyadd: ACLACL: 47#subtree#[Root]#[All Attributes Rights]- delete: ACL-replace: ACLACL: 47#subtree#[Root]#[All Attributes Rights]

Using LDIF

• ICE ConsoleOne or command line

• LDAP utilities SDK tools or OpenLDAP

C is Cool, but Perl is Cooler

• Net::LDAP Perl module One of a few Perl LDAP APIs My personal favorite (no C code, efficient, easy

to code)

• Installing Available with standard Linux distros Or just get it from perl-ldap.sourceforge.net,

or from CPAN Need OpenSSL to do secure binds

Manipulating ACLs in Perl

• Read/write attributes

• $ldap->modify(dn, changes=>[add => [ACL => “47#subtree#cn=jworfin,ou=propulsion,o=yoyodyne#[All Attributes Rights]”]]);

modifyACL.pl

• modifyACL.c ported to Perl

Effective Rights in Perl

• Perl-LDAP does not support extensions

• Of course, when your connection handle object is initialized and you perform the bind on it, LDAP is accessed as the authenticated user

Other Languages

• PHP• Python• Java• Anything else with an LDAP SDK or utilities• After all, they’re just attributes

Defining and Enforcing an eDirectory Security Infrastructure

• Understand what eDirectory is doing for you by default

Assess and evaluate what Default ACLs do Bind to the tree as the anonymous user, see

what you find Periodically redo this, especially after installing

new applications

• Make sure you understand inheritances and IRFs

• Work from the top down and bottom up

eDirectory Tree Design Considerations

• Sociopolitical concerns, structural concerns, geographic concerns

• Why does the developer care? Tree design affects how code is written and

implemented ACLs affect programming design Usefulness of eDirectory and associated code is

enhanced by well-defined security infrastructure

First Principles

• KISS• Least privilege• Leverage inheritance whenever possible• Minimize IRFs• Use groups when you can

Keep It Simple, Silly

• Design the tree as simply as possible, but with enough structure so that rights assignment can be done in appropriate places for maximum effect

• Although applying ACLs to a tree can be done as much as you want, and wherever you want, you’ll go insane trying to keep track of it all if you don’t limit it whenever you can

But, then again, part of the power of eDirectory is the precise control you can give to rights management

Just don’t overdo it

Least Privilege

• Always work your security structure from the “nobody gets access to anything” point, and then add just the rights needed to get their job done

• When setting up users or groups of users to have enhanced access, add the specific rights necessary

For instance, only the write right to an attribute, not Supervisor to the entire object

Requires a bit more testing, and planning, but it’s your tree at stake

Leverage Inheritance Whenever Possible

• Both in the trustee of an object and the object itself, whenever you can use container objects to apply ACLs, you’ve simplified the total number of rules in your tree, and that’s a good thing

• If the tree design is intuitive, inherited rights will be self-documenting

Minimize IRFs

• IRFs are great—one of the things that makes eDirectory the bee’s knees

• However, IRFs are hard to debug when something goes wrong and cause strange things to happen

• If you find yourself applying IRFs everywhere to fix problems with inherited ACLs, your tree design is likely not optimal

Use Groups When You Can

• Okay, inheritance is great and all that, but sometimes you just need to use groups

• Always use groups or organizational roles when you have to assign multiple people rights to an object, that aren’t already grouped in an organizational unit (OU)

One ACL on the object is easier to read both by system and human

Assigning that right to another person is a simple group membership operation instead of yet another ACL on the object

Dynamic Groups

• Use Dynamic Groups when you want to group people by attributes (location, department name, supervisor, etc.)

• Dynamic groups will have a performance hit depending on the complexity of the LDAP search involved and the size of the tree

• Dynamic groups do not update securityEquals of the member objects, so tests on that will not work

Auditing Your eDirectory Security Infrastructure

• Using the Get effective rights extension can be helpful to see all rights

Only does one object at a time, though Doesn’t fully map out functional relationships

• Graphical tools are good for this ConsoleOne—but again, only single objects

largely eDirectory auditing tools

Reference Materials

• Books LDAP Developer’s Guide, Novell Press

• RFCs/Internet Drafts LDAP v3: RFCs 2251-2256 search.ietf.org/internet-drafts/draft-sermersheim-nds-ldap-

schema-02.txt • Web sites

LDAPZone: www.ldapzone.com AppNotes: developer.novell.com/research Novell Documentation: www.novell.com/documentation

• Developer dit items LDAP Libraries for C (UNIX, NetWare, Windows) developer.novell.com/ndk

• Newsgroups novell.devsup.cldap, novell.devsup.cldaplin,

novell.devsup.cldapsol

Conclusions

• The developer needs to have a good understanding of ACL behavior in eDirectory to write useful and secure applications

• Using ACLs in LDAP is a simple case of reading and writing attributes to an object, and utilizing the effective privileges extension to determine specific objects’ rights to the tree

• Good tree design makes programming easier• LDAP can be done with any SDK or language

and is basically the same in all of them