WritingAccessControlPolicies forLDAP

30thJanuary2009 AndrewFindlay Skills1stLtd www.skills1st.co.uk

Synopsis
AccessControlsystemsvaryfromoneLDAPservertothenext.Allofthem canimplementsimplepolicies,butitmaybenecessarytodesigntheDIT aroundtheaccesscontrolrequirements.Inmorecomplexcasesitis essentialtochooseaserverwithaveryflexibleaccesscontrollanguage. ThereareanumberofpitfallsinACLdesign,andsomerequirementscannot beimplementedbymanyofthecommonlyusedserverproducts. Thispapersuggestsanapproachtodesigningandtestingaccesscontrol rules.Itincludesworkedexamplestoillustratesomecommonusecases.

DrAndrewFindlay Skills1stLtd 2CedarChase Taplow Maidenhead SL60EU +441628782565 [email protected]

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page1of44

1WhyUseAccessControl?
Directoriesoftenholdsensitiveinformation:names,addresses,userIDs, passwords,listsofpermissions...thelistisendless.Thisinformationalways needsprotectionagainstunauthorisedmodification,andoftenhastobe protectedagainstunauthorisedaccess.Atthesametime,thedirectorymust bekeptuptodateandaccessedbythoseauthorisedtodoso. Organisationsusuallyhavepoliciesgoverningwhomayaccessandmodify information.AccessControlisthemechanismusedtoenforcethosepolicies.

2LDAPAccessControlSchemes
Mostdirectoryserversprovidesomekindofaccesscontrollanguage,butthe exactformvariesfromoneproducttoanotherforhistoricalreasons. TheoriginalX.500(1988)standardexplicitlyavoideddefininganaccess controlscheme([X50088]section7.1.2).Asaresult,earlyimplementations suchasQuipuwerelefttodefinetheirown.LDAPwasoriginallybasedon X.500(1988)soitinheritedthislackofstandardisation.The1993revisionof X.500[X50093]introducedaverycomprehensiveaccesscontrolscheme,but thiswaswidelyregardedasovercomplexsoitdidnotgetimplementedin serverproductsorcarriedoverintoLDAPwhenother1993conceptswere incorporatedin1997[RFC2251][RFC2252].Bythistimetherewere standaloneLDAPserverssuchasMichigan'sslapdaswellasLDAPtoX.500 gatewaysinuse,sothenumberofaccesscontrolschemescontinuedto grow. ThesituationtodayisthatX.500(2005)containsacomprehensiveif complexaccesscontrolsystem[X50105],butLDAPleavesthisaspectfor implementerstodefine.ItshouldbenotedthatLDAPdoesdefine authenticationmethodsandsecuritymechanisms[RFC4513]. ExistingLDAPaccesscontrolschemescanbebroadlydividedintotwotypes: 1. Accesscontrolrulesheldindirectoryentries,usuallyinthepartof theDITthattheycontrol. 2. AccesscontrolrulesheldoutsidetheDIT. Rulesinthefirsttypeareusuallyunorderedsets,whilethesecondtypecan resembleprogramminglanguages.

2.1Concepts
Allaccesscontrolsystemsmustdealwiththesamesetofconcepts,though thetermstheyusetodescribethemmaybedifferent.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page2of44

2.1.1Subject TheSubjectisthepersonorotherentitythatisrequestingaccess.Itmight bedefinedbytheDNofasingleentry,theDNofagroup,orperhapsbya ruleorLDAPsearchfilterthatmatchesanumberofentries.Subjectsmight alsobecalledprincipalsorusers. Mostschemeshaveanexplicitrepresentationofanonymoususers,oftenin theformofaspecialDNsuchascn=any. UserscanidentifythemselvestoanLDAPserverindifferentwayswith varyinglevelsofsecurity,sosomeschemesallowtherequiredauthentication strengthtobeincludedintheaccesscontrolrules. 2.1.2Object TheObjectisthethingthatisbeingaccessed.Someserverscallitthetarget. Objectsincludeentireentries,attributes,andpossiblyparticularvaluesof thoseattributes.MostLDAPoperationsrequireaccesstoatleastoneentry andatleastoneattributewithinthatentry. Inaccesscontrolrules,objectsareoftendefinedbyfiltersandsearch strings,e.g.AllinetOrgPersonentriesunderdc=example,dc=org 2.1.3Access ThetypeofaccessgrantedwillaffectwhichLDAPoperationscanbe performed.MostLDAPserversprovideasetofaccesslevelssuchas:

Addanentry Deleteanentry Accessanentry(doesnotgiveaccesstoanyattributes) Readanattribute Modifyanattribute Searchanattribute

MostLDAPoperationsrequireacombinationofthesepermissions. 2.1.4ACI AnAccessControlItemisaruleortuplethatdefinesalevelofaccessfor somesubject(s)tosomeobject(s). 2.1.5ACL AnAccessControlListisalistofACIs.Dependingonthelanguageusedby theserverthelistmaybeorderedortheitemsmayhavethesameeffect whateverordertheyarewrittenin.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page3of44

2.2RelatedConcepts
Serversusuallyprovideotherformsofadministrativecontrol,whichmayor maynotbeintegratedintotheaccesscontrollanguage.

Sizelimits:theserestrictthenumberofsearchresultsthatcanbe obtainedfromasingleLDAPoperation. DITContentRules:thesecontroltheattributesandauxiliaryobject classesthatcanbeplacedinentriesofagivenstructuralclass(see section4.1.6of[RFC4512]).Theyarecloselyrelatedtoschema,butin someserversareimplementedaspartoftheaccesscontrolsystem. DITStructureRules:thesedefinethetypesofentrythatcanappearin eachpartoftheDIT.Theyarenotwidelyimplemented.

3LDAPServers
TheaccesscontrolcapabilitiesofsomerepresentativeLDAPserversare summarisedinthissection.

3.1NetscapeDS/SunDSEE/RedHatDS/iPlanetDS/FedoraDS
ThisisafamilyofsimilarproductsderivedfromtheoriginalUniversityof Michiganslapdserver.AccesscontrolinformationisstoredinACIattributes, andcanbeplacedinanyentrythatisadirectancestoroftheentrybeing controlled.Thesyntaxispowerful,withsupportfor:

Targetentryselectionfilters Attributelists Wildcardsintargetspecification Subjectselectionbyfilter Bindstrengthspecificationforsubjects Groupsubjects(thoughthegroupobjectislimitedtoapredefinedlist ofobjectclasses) MacroACIsavaluematchedinthetargetspecificationcanbe substitutedintootherfieldsintherule.

Wheremultiplerulesapplytothesametarget,theyarecombined.Deny rulesalwaysoverridegrants. TheseserversdonotimplementDITContentRules,buttheydooffersome controloveraddedentriesastheproposedentryissubjectedtoasubsetof thefullaccesschecksbeforebeingcreated.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page4of44

3.2IBMTivoliDirectoryServer
TDSprovidestwotypesofaccesscontrolrules:filteredandnonfiltered. BotharestoredintheDITbutcannotbecombinedinoneentry.Filtered ruleshavearichersyntaxandaremoreflexiblethantheearliertype. Filterscanonlybeusedintargetselectionnottodefinesubjects.Theyare standardLDAPsearchfilters,andthereisnoregularexpressionormacro facility. Rulescancontroltheaddentrypermission,butifthisisgrantedthereisno waytocontrolwhatisadded.TDSdoesnotimplementDITContentRulesor DITStructureRules. Groupsmaybeusedinaccesscontrolrules.Dynamicgroupsandnested groupsaresupported. Thereisausefulsetofattributeclasses,whichallowsaccesscontrolrulesto addressawholeclasswithouthavingtolisteachattributename.New attributescanbeassignedtooneoftheseclasses,butitisnotpossibleto createnewclasses.

3.3ApacheDS
Thisisarelativelynewprojectwhichplanstoimplementarichsupersetof LDAPfromthegroundupwards.Interestingly,itappearstohaveadoptedthe X.500administrativemodelandtheassociatedaccesscontrolsystem.

3.4OpenLDAP
OpenLDAPisuniqueinthelistofserversconsideredhere.Ithasanaccess controlsystemthatlookslikeaprogramminglanguage,andclausesare evaluatedinadefinedorder.Thelanguageisverypowerful:

ObjectentriescanbeselectedbyDN,subtree,LDAPsearch,orregular expression. Objectattributescanbeselectedbyname,objectclass,orlist Individualattributevaluescanbeselected SubjectscanbeselectedbyDN,subtree,LDAPsearch,byreferenceto avalueintheobjectentry,andbysubstitutionofvaluesmatchedina regularexpressionwhileselectinganobject. Bindstrengthandencryptionrequirementscanbespecified. ThereisasyntaxforconnectingobjectsandsubjectsusingVenn diagramlikesets. Accesscanbeexplicitlygrantedordeniedforread,write,search, compare,authenticate,anddiscloseonerror.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page5of44

Rulescanterminatetheaccessevaluationorallowexecutiontodrop throughtofurtherrulesintheset.

OpenLDAPimplementsDITContentRules,andalsoenforcesaccessrules whenaddingentries.Itistheonlyserverconsideredherethatisableto preventamalicioususerfromdiscoveringtheexistenceofanentrythatthey cannotread(thoughcareisrequiredifapplyingthistononleafentries).

4DefiningtheRequirements
MostdesignsstartwithasimplepolicyalongthelinesofKeepthebadguys outandprogressthroughanumberofiterationswheretherequirementsof theNotBadGuysarediscoveredandincluded. Itisworthtryingtokeepthepolicyassimpleaspossible,aswritingaccess controllistscanbehardandthecomplexitycangoupmuchfasterthanthe numberoflinesinthepolicy.Itisalsoimportanttorememberthatthe policy(andthustherulesthatimplementit)willprobablyhavetobe changedinthefuture:whoeverdoesitwillhavetogainadeep understandingoftheexistingsystembeforetheycansafelymoveforward. Whendiscussingtheaccesspolicyitisusefultohaveadiagramofthe proposedDITwithsomesampleentriesinit.Youcanthenaskquestions suchasShouldthispersonbeabletodothisoperationonthisentry?The answershelptorefinethepolicy,andalsodirectlycontributetothetest suite. Herearesomesamplepolicies.Theearlyonesarefairlysimple,andcouldbe adoptedwithouttoomuchdetaileddiscussion.

4.1Publicreadonlypolicy
Everyoneintheworldcanreadallentries:theycanseeall attributesexceptuserPassword. Changescanonlybedonebytheadministrator.

4.2Userreadonlypolicy
Authenticateduserscanreadallentries:theycanseeallattributes exceptuserPassword. Theownerofanyentry(whopresumablyknowstheexisting password)canchangetheuserPassword. Otherchangescanonlybedonebytheadministrator.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page6of44

4.3Delegatedadministrationpolicy
Everyoneintheworldcanreadallentries:theycanseeall attributesexceptuserPassword. Eachdepartmentintheorganisationhasagroupofclerksto maintainthedirectory.Clerksmaycreateandmodifyperson entriesinthedepartment'speopleareaandgroupentriesinthe department'sgroupsarea.(Notethatthisallowsanexistingclerk tocreateanewonewiththesamepowers.)

4.4Controlledvisibilitypolicy
Everyoneintheworldcanreadentriesthataremarkedaspublic: theycanseeallattributesexceptuserPassword. Authenticateduserscanreadallentriesintheirowndepartment: theycanseeallattributesexceptuserPassword. Usersmaychangetheirownpasswords.

4.5Subsetvisibilitypolicy
Entriesareexplicitlymarkedwithavisibilitycategoryinthe exampleVisibilityattribute:

internetallowsthewholeworldtoseetheentry. usersallowsallauthenticateduserstoseetheentry. departmentallowsauthenticatedusersinthesame departmenttoseetheentry. anyothervalue(ornone)meansthatonlytheentryowner canseeit.

Visibilityofattributesisalsotobecontrolled.Innonperson entries,onlyobjectclass,o,ou,dc,descriptionattributesshallbe visible.Personentriesshallbecontrolledindetail:

Anonymoususerscansee:objectclass,cn,sn,displayname, mail,uniqueIdentifier Authenticateduserscanalsosee:telephoneNumber Samedepartmentuserscanalsosee:uid

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page7of44

Userscanalsoseetheirown:description,exampleVisibility

UsersmaychangetheirownuserPasswordandexampleVisibility attributes. Allotheraccessisdenied Notethatthisisadefaultdenypolicy,soitdoesnotneedtosay anythingaboutprotectinguserPasswordvisibility.

5DesignPrinciples
Therearenohardandfastrulesforwritingaccesscontrollists,andthe varyingcapabilitiesofdifferentLDAPserverssometimesrequirevery differentapproaches.However,Ihavefoundtheseprinciplestobeauseful guide: 1. ACLsareprogramstheyshouldbehandledbyprogrammers,notby dataadministrators. 2. PlaceACLsonthesmallestpossiblenumberofentries.Iftherearelots ofsimilarACLscontrollingdifferentpartsoftheDITthenitbecomes hardtochangethemifthepolicychanges. 3. TrytokeepACLsoutofentriesthatneedtoberoutinelycreatedand deleted.Thiscanbedifficultonsomeservers,particularlywhere regularexpressionsandmacrosarenotavailable. Thisfollowsfromprinciples1and2. 4. DITandschemadesignmaybeaffectedbyACLcapabilities.Ifdifferent entriesshouldhavedifferentaccessrulestheneitherthecontentof theentry,itsmembershipofsomegroups,oritspositionintheDIT mustbeusedtoselectwhichrulestoapply. 5. Addnewattributestotheschematodriveaccesscontrol. Administratorscancontrolthevaluesoftheseattributeswithout havingtounderstandtheACLimplementation. 6. Writethetestsfirst,asthishelpstoclarifyexactlywhatthe requirementsare.Keepthetestsuiteuptodateandrunitfrequently whenworkingonACLs. 7. TrytowriteACLsonthe'defaultdeny'principle.Itiseasierto understandandverifytheACLsifyoudonotmix'grant'and'deny' rules.Thisismoreimportantinthe'ACLsasattributes'systemthanit iswhereACLsbehavelikeprograms. 8. Don'twriteindividualaccountIDsintoACLs:givepermissionsto groupsandallowadministratorstocontrolmembershipofthegroups.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page8of44

9. Dynamicgroupscanoftenbeusedtoidentifysubjectsiftheaccess controllanguageisnotflexibleenoughtodoitdirectly. 10.Don'tforgetthatsomeLDAPserversdonotenforcethesamerules whenaddinganentrythattheydowhenmodifyingthesameentry later.Thiscanmakeitimpossibletocontrolthetypeofentriesthat administratorscancreate. 11.DITContentRulescanbeusefultocontrolwhichauxiliaryclassescan beusedwitheachstructuralclass.TheycanalsoaddtotheMUST andMAYlistsandsubtractfromtheMAYlistofattributes.Thisis oftenbetterthanusingACLstocontrolthecontentofentries.Notall serversimplementtheserules. 12.DITStructureRulescanbeusefulincontrollingtheshapeoftheDIT, butveryfewserversimplementthem. 13.Searchlimitscanalsobeusefulinaccesscontrol. 14.DesigntheDITsothatDNsdonotexposesensitiveinformation.Many LDAPserversareunabletopreventanattackerfromdetectingan entrywhosenametheyhaveguessed.Somewillevenreturnanentry (andthusitsRDN)whentheRDNattributeisnotsupposedtobe visibletotherequestinguser. 15.AvoidspacesandpunctuationinRDNs,asthiscanmakeregular expressionsanddynamicgroupattributeshardertoconstruct. NamingentrieswithopaquehexadecimalorBase64valuesof uniqueIdentifiersatisfiesthisprincipleandthepreviousone. 16.RemembertogiveANONenoughaccesstotherootDSE.SomeLDAP clientswillnotstartproperlyiftheycannotreadcertainattributes fromtherootDSE. 17. ANONmayneedsomeaccesstouserentriestopermitauthentication. ThiscanbeparticularlyawkwardwhereLDAPclientsexpecttouseuid ormailaddressratherthanDNtoidentifytheentrytobind. 18.Bewaryofsubtreereplication:thereplicaserversmaynotcontainall theACLs(orentriesprovidingdataforACLs).

6SchemaDesign
LDAPstoresinformationasattributesinentriesandalsointhestructureof theDIT.Therearetradeoffstobemadeandthefinaldesignmusttake accountofaccesscontrolpolicyaswellasthestructureoftheinformationto bestored.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page9of44

6.1DITshape
InLDAPSchemaDesign[FINDL05]Isuggestcollectingallpersonentriesinto asinglelocation.ThisisagoodpolicyforaDITservingasingleorganisation. Iftheaccesscontrolpolicyistobebasedonmembershipofparticular departmentsorgroups,thereneedstobesomewaytodefinethat membership.Thetwoobviouschoicesare: 1. Anattributeineachentry 2. AgroupobjectelsewhereintheDIT Eachhasadvantagesanddisadvantages,andthechoicewilldependtosome extentonhowtheentriesaretobemanaged.Infactthetwoconceptsare notmutuallyexclusive:mostLDAPserverssupportdynamicgroupswhose membershipisdefinedbyasearchstring(andthusbyentryattributes). Usingsuchadynamicgrouptodefineaccessrightsisanobvious development. WhereasingleDITmustserveanumberoforganisations(e.g.inaservice providerenvironment)itislikelythataccesspolicieswillbedefinedinterms ofpositionintheDIT.Serversthatimplementmacrosorregularexpressions intheiraccesscontrollanguagehaveanadvantagehere,asasinglerulecan bewrittentoapplytoallorganisations.IfusingalesscapableLDAPserverit willbenecessarytodefineoneormoredynamicgroupsforeach organisationandtocreateACLsreferringtothembyname.

6.2Attributes
Itisoftenusefultoaddnewattributesspecificallytodriveaccesscontrol rules.Peopleoftenaskforan'exdirectory'attribute,butinkeepingwiththe designprinciplesinsection5above,Iprefertouseanattributethatgrants specificlevelsofaccess.ThusadesignforTheExampleOrganisation wouldincludeatextattributecalledexampleVisibilitywithadefinedsetof values.Anentrywithnovalueinthisattributewouldnotbevisible(except perhapstoadministrators).Values'department','organisation','world'would giveprogressivelywidervisibilitytotheentry.

6.3Usinggroups
Anotherapproachtocontrollingvisibilitywouldbetomake exampleVisibilityaDNvaluedattributeanduseittolistgroupsthatinturn listuserswhomayseetheentry.Apotentialproblemwiththisschemeis thatsomeLDAPserversmaynotbeabletorepresentanonymoususersin groups.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page10of44

7TheProcessofWritingtheACLs
7.1Requirementscapture
Asmentionedinsection4above,itislikelythatthiswillbeaniterative processtightlycoupledwithschemadesign.InthefirstroundIgenerallytry toestablishabroadpicture:

Whatarethesubjects(section2.1.1)andhowcantheybegroupedinto classes? Whataretheobjects(section2.1.2)thatwemustcontrolaccessto? Don'tforgetthenonleafobjectsthatmakeupthestructureoftheDIT. Whatisthesecuritypostureoftheorganisationopentotheworldor tightlyclosed? Howwillentriesbecreatedandmanaged?Ifthedirectorywillbethe mastersourceofdata,whowillbeadministeringit? Whatwillthedirectorybeusedfor?Whataccessisrequiredforeach applicationtowork?

WorkingfromthatinformationIproduceoneormoreoutlinedesigns, concentratingontheoverallshapeoftheDIT.Thesedesignsformthebasis forasecondroundofdiscussionwherespecificusecasescanbefittedinto themodel.Itisoftenusefultoworkthroughsomerealexamplestoseehow thedatawillberepresentedandused.Atthispointitispossibletopointto anobjectintheDITandaskwhataccessspecificsubjectsshouldhavetoit. Eachofthesequestionsandanswersshouldberecordedcarefully,aseach oneshouldprovidematerialforatleastonetestinthetestsuite.

7.2BuildaTestSuite
Oncetheinitialschemadesignhasbeenagreed(andsometimesbeforethat iftherearesignificantchoicestobemade)IalwaysbuildasampleDIT.This hasthemainstructuralcomponentsandanumberofexampleleafentries representingthemaintypesofdatatobestored.TherearenoACLsyet,but thereareenoughentriestoalloweachquestionfromthefirststagetobe represented. ThesampleDITcanbegiventoapplicationdevelopersatthisstage,sothey canmakeprogresswhiletheACLsarebeingwritten. ThenextstepistostartwritingtheACLtestsuite.InormallyusePerlfor this,withtheNet::LDAPandTest::Simplemodules.Thestructurefollowsa simplepattern:

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page11of44

1. OpenanumberofLDAPconnectionstotheserverandbindeachasa differentsubject.Thisusuallyincludes: Anonymous TheLDAPservermanager(rootdn)thisuserisnotsubjectto accesscontrol. Oneormoreaccountsrepresentingdifferentclassesofuser: ordinarypeople,adminstaff,automaticprocessesetc. 2. Foreachclassofobject,testthereadaccessgrantedtoeachclassof subject. 3. Testwriteaccess. 4. Testcreationanddeletionofentries. Evenasimpleaccesspolicycangiveriseto50ormoretests.

7.3ChooseaStyle
AccesscontrollanguagesmaynotbeasexpressiveasPerl,butinmostcases thereisstillmorethanonewaytodoit. 7.3.1Grantsonlyormixed? ACLscanbewrittenentirelyusinggrantrules,leavingallnondefined accesstobedeniedbythedefaultdenyrulethatisbuiltintomostLDAP servers.Thisisprobablythesafestoption,andisusuallytheeasiestto understandwhenworkingwithnonorderedACLs(mostserversthatkeep ACLsinattributeswithinthemainDIT). AtfirstsightthisapproachwouldseemtogenerateverylargeACIsaseach attributehastobeexplicitlycontrolled,butmechanismslikeTDI'sattribute classesandOpenLDAP'suseofobjectclassesinACLshelptokeepthesizein check. Forverysimplecases,amixtureofgrantanddenyrulescanresultina smallerACLtoachieveagivenresult.Thisiscommonlyusedwherethe accesspolicysayssomethinglikeEveryonecanreadeverythingexcept userPassword.Therearerisksthough:userPasswordmaynotbetheonly attributethatstorespassworddataandthisrulewouldleavetheother formsunprotected. 7.3.2Matchanddefineoraccumulatepermissions? MostserversallowmorethanoneACItocontributetoagivenaccess decision.Thisallowsfortwodistinctstyles:

EachACImatchesaparticularcaseanddefinestheentireaccessfor thatcase.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page12of44

TheaccessgrantedbyseveralACIsiscombinedtomakethefinal decision.

IfusingthesecondstyleitisbesttoavoiddenyACIsastherulesfor combiningthesewithoverlappinggrantscanbedifficulttodealwith(even iftheyaredocumented,whichisnotalwaysthecase!) 7.3.3Separaterulesforreadandforwrite? Ifaccumulatingpermissionsitispossibletouseseparaterulesfor read/searchoperationsandforwrite/add/deleteoperations.Incomplex casesthismayhelptomaketheruleseasiertounderstand.

7.4Choosecontrolpoints
Inmanycases,somerulesapplyonlywithinaparticularsubtreeoftheDIT. Therootofeachsuchsubtreeisanobviousplacetoputtherules(oratleast tohavethemtakeeffectfrom). Thedesignprinciplesinsection5abovesuggestthatthereshouldbeasfew controlpointsaspossible,soruleswillnormallytakeeffectfromhighupin theDIT. Whereruletargetsaredefinedbyfiltersorregularexpressionsitmaybe possibletoplaceeveryruleattherootsuffixoftheDIT.Thishasthe advantagethatanylaterextensionoftheDITwillbecoveredautomatically.

7.5WriteandTestACLs
Thistendstobeaniterativeprocess,startingwithasimplerulegivingbasic accesstoanonymoususers.Iwouldexpecttowriteoneortworulesand thenrunthetestsuitetochecktheeffect. Ifusingthegrantrulesonly(defaultdeny)schemeitshouldbepossibleto writerulesthatdonotinterferewitheachother,butinpracticethisisquite hardsoyoushouldexpecttogobackandmodifyearlierrulesastheACLs develop. TheprocessofwritingACLsusuallysuggestsmoretests,andtheseshould bewrittenstraightaway.

8Serverspecifics
EachfamilyofLDAPservershasitsownaccesscontrollanguage.The principlesaresimilaratfirstsight,butimplementationdetailsvary considerably.Thismeansthattheapproachtoimplementingaparticular policycouldbeverydifferentforeachserver:infacttherearepoliciesthat someserverscannotimplementatall. Itisessentialtohavetheserver'stechnicaldocumentationtohandandto readitverycarefully.ACLscanhaveeffectsthatarenotintuitivelyobvious,
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page13of44

anditissometimesnecessarytorunserversindebugmodetounderstand whytheybehaveinparticularways. Thissectionpointsoutoneortwofeaturesofeachserver'sACL implementation.Itisalongwayfrombeingcomprehensive.

8.1NetscapeDS/SunDSEE/RedHatDS/iPlanetDS/FedoraDS
ACIscanbeplacedinanyancestoroftheentrytheyaretocontrol.The controlpointisdefinedbythetargetclause,whichisanLDAPURL. Groupsusedinaccesscontrolmustbeoneofthestandardgroupclasses. Inventinganewgroupclassandaddingmemberattributesdoesnotwork. MacrosareapowerfulfeaturethatcanbeusedtomakeasingleACIapplyto manysimilartargets.Forexample,ifanACI'stargetisdefinedas "ldap:///($dn),dc=example,dc=org"thentheassociatedsubject (userdn)canbedefinedas "ldap:///dc=people,[$dn],dc=example,dc=org??sub?"theeffectisto maketheruleapplywhereauserisaccessingentriesintheirown department(seeexamples10.3and10.4). TheserverappliesACLstothecontentofanentrythatisabouttobeadded, butitallowstheaddtoproceedifitfindsanywriteableattributes.This providessomecontroloverthecreationofentries,butisnotenoughtobe completelysafe.

8.2IBMTivoliDirectoryServer
ThedefaultACLlookslikethis: aclentry: group:CN=ANYBODY:system:rsc:normal:rsc:restricted:rsc Itgivesworldreadonlyaccesstothecommonattributesofallentries. However,ifyouaddanyACLtotheDITitwilltotallyoverridethedefaultin itssubtree.Ifyouwanttocombineextrapermissionswiththedefaultthen youmustaddtheaboveACIexplicitly. TDSsupportstwotypesofACLforhistoricalreasons.Foranynontrivial task,itisprobablybesttousefilteredACLsalone. Thereisnowaytocontrolthetypeandcontentofnewentries:onceyou grantanaccount'a'permissiononanodetheycancreateanythingtheylike underiteveniftheycannotthenmodifywhattheyhavecreated.Ifthe attackerrememberstomakethemselvestheowneroftheentrywhenthey createitthentheyhavetotalfreedomtodowhattheywantwithitinthe future. TDSdoesnotsupportmacrosorregularexpressionsinACLs.Thismakesit veryhardtosatisfythefirstthreedesignprinciplesinsection5.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page14of44

8.3OpenLDAP
OpenLDAPsupportsoneACLperbackendplusadefaultACL.Thedefaultis appendedtoeachbackendspecificACL.ItisthereforewisetoendeveryACL withacatchallstatementsuchas: access to * by * none Alwaysturnonthecheckingofaddedentries: add_content_acl yes Thisfeaturewasintroducedinversion2.4.13anditcausesACLstobe appliedfullytothecontentofentriesthatareabouttobeadded.UseDIT contentrulestogainfurthercontrolofaddedentries. OpenLDAPallowsanobjectclassnametobeusedtodefinethelistof attributesthatanACIappliesto.Thisisaveryusefulfeature,particularlyif youdefinenewobjectclassesspecificallyforthepurpose.Seeexample10.5 wherethisisusedextensively. Ifbasinganaccessruleonavaluematchyoumustmakesurethatthe attributehasasuitablematchingruledefinedintheschema.Ifitdoesnot, thenyoucannominatearule: access to attrs=namingContext val/distinguishedNameMatch="o=example" by * none

9Gotchas
Howeverhardyoutry,therearesomethingsthatACLscannotprotect.The exactlistvariesfromoneservertothenext,butafewseemtobevery common. 1. Protectinganonleafobjectdoesnotprotectobjectsbelowitinthe DIT.Thus,evenifauserhasnoaccessatallto ou=deptA,dc=example,dc=orgtheycouldstillissueasearchthat wouldreturndatafromcn=private,ou=deptA,dc=example,dc=org 2. Itisveryhardtopreventamalicioususerfromprovingtheexistence ofanentrywhoseDNtheyhaveguessed.Eveniftheuserhasno accesstocn=secret,dc=example,dc=orgtheycanuseitasthebase ofasearch:ifitexiststheywillgetnoanswersbutnoerror,whereasif itdoesnotexisttheywillgetanosuchobjecterror. OpenLDAPprovidesthedisclosepermissiontocontrolthis,butis stillunabletopreventthedisclosureofnonleafobjectsthathave accessibleobjectsbeneaththem.Mostotherserversdonotattemptto controlthisdisclosureatall.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page15of44

3. ManyLDAPserversdonotapplyaccesscontroltothecontentsofan entrythatisabouttobeadded.Thusauserwhohaspermissionto createaddressbookentriesmaybeabletocreatenewaccounts, groupsetc.Evenifaccesscontrolisappliedtonewentrycontents,itis notalwaysdoneasthoroughlyaswhenmodifyingexistingentries.

10Examples
Inthesescenarios,theExampleOrganisationhasaDITrootedat dc=example,dc=org.ThediagramsshowthestructureoftheDIT,with heavyoutlinesindicatingthoseentriesthatarecreatedbeforethetestsuite runs. Asetoftestsisoutlinedforeachexample,andsampleACLsforseveral differentLDAPserversaregivenforcomparison.Lineshavebeenfoldedfor readabilitysothetextheremaynotbedirectlyloadable:refertotheexample distributionpackforusablefiles. WhereservershavedefaultACLsitisassumedthattheyhavenotbeen changed.InOpenLDAPtheACLspresentedhereareintendedtobeusedin thebackendconfiguration,alongwithasimpleworldreadACLintheglobal configuration: access to * by * read Adistributionpackcontainingallthefilesfortheseexamplesisavailable from: http://www.skills-1st.co.uk/pub/code/acl-examples.tgz

10.1ASimpleAccountRegistry
dc=example,dc=org

dc=people

dc=groups

uid=u1

uid=u2

uid=u3
Figure1:Simpleuserregistry

cn=g1

cn=g2

AverysimpleDIT(Figure1)andaverysimpleaccesspolicy.TheDIThas onearcforusersandoneforgroups.Everyone(includinganonusers)can
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page16of44

readallattributesexceptforuserPassword.Userscanchangetheirown passwords.Thissetupmightbeusedtosupportasimplewebsite.Itiscalled simpleinthedistributionpack. Theobviouscontrolpointisdc=example,dc=organdtheexpressionofthe policysuggeststhatwemightuseadenyruletocontroluserPassword. 10.1.1Tests Thisisaverysimplescenariobutitstillneedsquitealotoftests:

OpenLDAPconnectionsandbindthemasAnon,rootdn,and uid=u1,dc=people,dc=example,dc=org Readdc=example,dc=orgusingeachconnectionandcheckthatbasic dataisvisible. Readdc=people,dc=example,dc=orgusingeachconnectionand checkthatbasicdataisvisible. Readdc=groups,dc=example,dc=orgusingeachconnectionand checkthatbasicdataisvisible. Readuid=u1,dc=people,dc=example,dc=orgusingeachconnection andcheckthatbasicdataisvisible.Checkthattheanonandu1 connectionscannotreaduserPasswordfromu1'sentry. Checkthattheu1connectioncanreadeverythingexcept userPasswordfromu2'sentry. Usetheu1connectiontochangeu1'spassword.Checkthatthenew passwordworks. Ilikemyteststoreturneverythingtothebasicstartingpoint,soI wouldusetheu1ortherootdnconnectiontoresetthepasswordat thispoint. Checkthattheu1connectioncannotcreateormodifyentries.Check thatthecorrecterrorcodesarereturned (LDAP_INSUFFICIENT_ACCESSinthiscase)

10.1.2ACLsforSun/Netscapeservers Thedocumentationfortheseserverssaysthattheyallowworldreadaccess bydefault,butthatisnolongerthecaseintheversionthatItested(Sun DSEE6.0).ThefirstACIthereforeprovidespublicreadaccesstoall attributesexceptuserPassword.TheACIisstoredatdc=example,dc=org andhaseffectontheentiresubtreebelowthatpoint. Notetheuseofthenegativematchonthetargetattributes.Thiscanberisky (aswithothernegativeforms)becausetwoormoresuchACIsmaynot combineinthewaythatthedesignerexpects.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page17of44

TheDN"ldap:///anyone"isusedbythisfamilyofserverstoincludeall usersincludinganonymousones. dn: dc=example,dc=org changetype: modify add: aci aci: (targetattr != "userPassword") (version 3.0; acl "Make public objects visible to all"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) OnemoreACIisrequired,togiveuserstheabilitytochangetheirown passwords.Infact,thisispartofthedefaultsetbutincludingitexplicitly doesnoharm.Notethatthewritepermissiongrantedheredoesnotalso grantread,searchorcompare. # Allow users to change their own passwords # dn: dc=example,dc=org changetype: modify add: aci aci: (targetattr = "userPassword") ( version 3.0; acl "allow userpassword self modification"; allow (write) userdn = "ldap:///self";) ThetwoACIsarebothstoredinthesameentry,wheretheywilleachbecome aseparatevalueoftheaciattribute.Notethatthereisnoorderof preference:theycouldbeevaluatedinanyorder. ThisACLpassesallthetestsinthetestsuite. 10.1.3ACLsforIBMTDS TDSswitchestodefaultdenymodeassoonasitfindsanyACIthatapplies totheobjectbeingconsidered.WethereforestartbyaddinganACIto explicitlypermitreadaccesstodesiredattributes.Thecontrolpointis dc=example,dc=organdIhavechosentousefilterACLsthroughout. Notetheuseofattributeclassnormal.Thisclasscontainsordinary informationalattributessuchascn,sn,telephoneNumberetc.The userPasswordattributebelongstothecriticalclasssoitwillnotbe exposed. TDSusesthespecialgroupDNcn=anybodytodenoteallusersincluding anonymousones.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page18of44

dn: dc=example,dc=org changetype: modify add: ibm-filterAclEntry ibm-filterAclEntry: group:CN=ANYBODY:(objectclass=*):normal:rsc AsecondACIisneededtoallowuserstochangetheirownpasswords.This usesanotherspecialDN(cn=this)todenotetheuserrepresentedbythe entryitself.ThisACIgrantswriteaccesstothesingleattribute userPassword. dn: dc=example,dc=org changetype: modify add: ibm-filterAclEntry ibm-filterAclEntry: access-id: cn=this:(objectclass=*):at.userPassword:grant:w TwoACIsaresufficienttodothejob.Theyarebothstoredinthesameentry andtheorderinwhichtheyaredefinedisirrelevant. ThisACLpassesallthetestsinthetestsuite. 10.1.4ACLsforOpenLDAP OpenLDAPdoesnotplaceACIsintheDITthattheyarecontrolling.Current (2.4.x)versionsallowtheuseofconfigurationfilesoraconfiguration databaseaccessedthroughLDAP.Alltheexampleshereusethefileformat asthatisslightlysimplerthantheLDIFform. AnOpenLDAPACLhasadistinctflowofcontrol.Directivesareevaluatedin orderuntilaterminatingstatementisreached. ThefirstdirectiveinthisexampledealswiththeuserPasswordattribute, whereveritmayoccurintheDIT.Iftheattributeisbeingaccessedbythe userrepresentedbytheentryunderconsideration(by self)thentheaccess =wisgranted.Thismeansthatwriteoperationsarepermittedbutothers arenot.Thecaseofauseraccessingtheirownpasswordiscompletely definedbythisstatement.AnyotherusertryingtoaccesstheuserPassword attributewoulddropthroughtothenextbyfield,whichisdesignedto matchallusersincludinganonymousones.Theaccessgrantedisauth whichistheminimumnecessarytosupportauthentication.Allpossible subjectswantingaccesstotheuserPasswordattributehavenowbeen covered,soevaluationwouldstophere.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page19of44

access to attrs="userPassword" by self =w by * auth Theseconddirectivehandlesaccesstoallotherattributesandpseudo attributes.Itallowseveryonetoreadeverything.Thisdoesnotexpose userPasswordasthefirstdirectivecoveredallaccesstothatattribute. access to * by * read ThisACLpassesallthetestsinthetestsuite.

10.2AddingaDataAdministrator
Thisisanextensionoftheaccountregistryexample.Poweristobe delegatedtoadataadministrator,whowillbeallowedtocreateandmodify personandgroupentries.Topreservesanity,theadministratorislimitedto creatingeachtypeofentryinthecorrectpartoftheDITandisnotpermitted toaddanyauxiliaryobjectclasses. Notethattheadministratorisnotthedirectorymanagerorrootdn:these termsrefertoanallpowerfulaccountthatisnotsubjecttoaccesscontrol.

dc=example,dc=org

dc=people

dc=groups

uid=admin

uid=u1

cn=g1

cn=g2

Figure2:Delegatedadministration

Thisiscalledstructurecontrolinthedistributionpack.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page20of44

Therequirementtolimitwhattypeofentrycanbecreatedundereacharc meansthattherewillhavetobethreecontrolpoints:

dc=example,dc=org dc=people,dc=example,dc=org dc=groups,dc=example,dc=org

10.2.1Tests Mostofthetestslistedforthesimplescenarioinsection10.1.1alsoapply here.Inaddition,testsareneededfor:

Thedelegatedadministratorshouldbeabletocreateandmodify personentriesunderdc=people,dc=example,dc=organdgroups underdc=groups,dc=example,dc=org Thedelegatedadministratorshouldnotbeabletocreateentriesofthe wrongobjectclassineitherlocation. Thedelegatedadministratorshouldnotbeabletoaddunwanted attributesorobjectclassestoanyentry.

10.2.2ACLsforSun/Netscapeservers ThefirstACIisthesameasforthesimpleaccountregistryinsection10.1:it givespublicreadonlyaccesstoallattributesapartfromuserPassword. dn: dc=example,dc=org changetype: modify add: aci aci: (targetattr != "userPassword") (version 3.0; acl "Make public objects visible to all"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) ThenextACIcontrolswhatthedelegatedadministratorcandointhe dc=peoplesubtree.NotethattheACIitselfisplacedatdc=example,dc=org buthasitstargetsettodc=people,dc=example,dc=org. TheACIhasatargetfilterthatrestrictsittoobjectsofclasspersonor account.Asthisfamilyofserversappliessomeaccesscontrolrulestothe contentofnewentries,thisshouldpreventtheadministratorfromcreating oreditingentriesofothertypes.Notethatitcannotpreventthemfrom addingauxiliaryobjectclasses. Asafurtherprotection,theACIhasalistoftargetattributes.Thisrestricts theattributesthattheadministratorcanmodifyinexistingentries. Unfortunatelythisprotectiondoesnotapplywhencreatingnewentries,so theadministratorcanaddanyattributestheylikeprovidedthenewentry hasastructuralobjectclassofpersonoraccount.
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page21of44

dn: dc=example,dc=org changetype: modify add: aci aci: (target = "ldap:///dc=people,dc=example,dc=org") (targetfilter = "(|(objectclass=person)(objectclass=account))") (targetattr = "cn || sn || uid || description || userPassword || objectclass") (version 3.0; acl "Admins may add and modify users in the people arc"; allow (write, add, delete) (userdn = "ldap:///uid=admin,dc=people,dc=example,dc=org") ;) TheremainingACIcontrolsaccesstothedc=groupssubtree.Ithasfilters andattributelistsanalogoustothoseusedfordc=people. dn: dc=example,dc=org changetype: modify add: aci aci: (target = "ldap:///dc=groups,dc=example,dc=org") (targetfilter = "(objectclass=groupOfNames)") (targetattr = "objectclass || cn || member || description") (version 3.0; acl "Admins may add and modify groups in the groups arc"; allow (write, add, delete) (userdn = "ldap:///uid=admin,dc=people,dc=example,dc=org") ;) TheACLsimplementmostoftherequirementsofthepolicy,buttheyfailto controlthecontentofnewentries(apartfromrequiringthemtocontainthe desiredobjectclass).Theredoesnotappeartobeawayaroundthisproblem inSunDSEE6.0. 10.2.3ACLsforIBMTDS Asinthefirstexample,anACLatdc=example,dc=orgwillgrantoverall readpermissionandwillalsoallowuserstochangetheirownpasswords.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page22of44

dn: dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: group:CN=ANYBODY:(objectclass=*):normal:rsc ibm-filterAclEntry: access-id:cn=this:(objectclass=*):at.userPassword:grant:w Thenexttaskistoallowtheadminaccounttoworkonpersonentriesinthe dc=peoplesubtree.ThisACLhastwoACIs:onetopermitthecreationof newentriesandonetopermitexistingentriestobemodifiedordeleted. EachACIhasafilterthatselectswhereittakeseffect.Attributesinthe normalclassaregivenread,write,searchandcomparepermissions,but userPasswordisonlygivenwrite:thisallowspasswordstobesetand changed,butnotread. dn: dc=people,dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: access-id:uid=admin,dc=people,dc=example,dc=org: (objectclass=organizationalUnit):object:grant:a ibm-filterAclEntry: access-id:uid=admin,dc=people,dc=example,dc=org: (|(objectclass=account)(objectclass=person)) :object:grant:d:normal:rwsc:at.userPassword:grant:w TheACLforthegroupssubtreeissimilar,butdoesnothavetoaccountfor passwords. dn: dc=groups,dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: access-id:uid=admin,dc=people,dc=example,dc=org: (objectclass=organizationalUnit):object:grant:a ibm-filterAclEntry: accessid:uid=admin,dc=people,dc=example,dc=org: (objectclass=groupOfNames):object:grant:d:normal:rwsc TDSdoesparticularlybadlyonthistest.Itiscompletelyunabletocontrol thecontentofnewentriessothepolicylimitingtheactionsofthe administratorcannotbeimplementedatall.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page23of44

10.2.4ACLsforOpenLDAP Thefirststepinimplementingthispolicyisnotanaccessruleatall,buta pairofDITContentRules.Theseconstraintheschemasothatnoauxiliary classescanbeaddedtopersonorgroupentries.Onceacontentruleisin force,eventherootdncannotbreakit. EachrulestartswiththeOIDoftheclassthatitappliesto.Notethatithas noeffectonsuperclassesorsubclasses:ifyouwanttocontrolthosethen theyeachneedanexplicitrule.Inthiscasethetworulesareenough becauselaterruleswillconstraintheadministratortoworkingon inetOrgPersonandgroupOfNamesentries,andneitherhasanysubclassesin theschemainuse. # Content rule for inetOrgPerson # ditcontentrule ( 2.16.840.1.113730.3.2.2 NAME 'dcrPerson' DESC 'Limit aux classes on inetOrgPerson entries' ) # Content rule for groupOfNames # ditcontentrule ( 2.5.6.9 NAME 'dcrGroup' DESC 'Limit aux classes on group entries' ) ThenextstepistoturnonstrictenforcementofACLswhennewentriesare beingadded.Thisfeaturewasintroducedinversion2.4.13andishighly recommended,thoughitisnotstrictlyneededinthiscasebecausetheDIT ContentRulesprovideenoughcontrol. add_content_acl yes ThefirstaccessrulecontrolstheuserPasswordattribute.Itisverysimilarto theruleinthesimpleexampleinsection10.1above,butnowhasafield givingwriteonlyaccesstothedelegatedadministrator. access to attrs="userPassword" by dn.exact="uid=admin,dc=people,dc=example,dc=org" =w by self =w by * auth Thesecondrulepermitstheadministratortocreatenewentriesdirectly underdc=people.Thisisdonebygrantingwriteaccesstothechildren

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page24of44

pseudoattribute.Therulehasnoeffectonotherusersduetothe by * breakfieldattheend. access to dn.exact="dc=people,dc=example,dc=org" attrs="children" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break Creatingentriesalsorequiresaccesstotheentrytobeadded.Thenextrule grantsthistotheadministrator,butonlywheretheobjectclassis inetOrgPerson.Thispreventsotherentrytypesfrombeingcreatedofmodified here.Again,therulehasnoeffectonotherusers. access to dn.onelevel="dc=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break Asimilarpairofrulescontrolsthecreationandmodificationofentriesunder dc=groups: access to dn.exact="dc=groups,dc=example,dc=org" attrs="children" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break access to dn.onelevel="dc=groups,dc=example,dc=org" filter="(objectClass=groupOfNames)" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break Finally,thedefaultaccesscoveringallothercasesisset: access to * by * read TheACLspassallthetests,showinghowusefulDITContentRulescanbe.It wouldbeveryhardtoimplementthispolicycompletelyusingaccesscontrol alone.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page25of44

10.3LimitingVisibilityofEntries
Inthisexampleweconsideranorganisationwithseveraldepartments.Some entriesaremarkedforpublicvisibilityusingtheexampleVisibilityattribute. Anythatarenotmarkedcanonlybeseenbyusersinthesamedepartment. Thisisthelocalvisibilityexampleinthedistributionpack.

dc=example,dc=org

dc=a

dc=b

dc=people

dc=groups

dc=people

dc=groups

uid=a1

uid=a2

cn=clerks

uid=b1

uid=b2

cn=clerks

Figure3:TheLocalVisibilityscenario

Thedepartmentsdc=aanddc=baremarkedforpublicvisibility,asisthe suffixnodedc=example,dc=org.Allotherentriesshouldbeprotected. 10.3.1Tests

Authenticateasusersa1,a2,b1,b2 Checkthatallusers(andANON)canreadthepublicentries CheckthatANONcannotreadorsearchotherentries Checkthata1canseea2andtheclerksgroupindepartmentA Checkthatb1cannotseeanythinginsidedepartmentA

Theapproachtoimplementingthispolicyisverydifferentforeachserver family.
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page26of44

10.3.2ACLsforSun/Netscapeservers Theseservershaveaveryusefulmacrofacility,whichallowsoneACLatthe rootofthetreetocontrolanynumberofdepartments. Publicvisibilityisimplementedusingatargetfilterthattriggerswhen exampleVisibilityispublic: dn: dc=example,dc=org changetype: modify add: aci aci: (targetfilter = "(exampleVisibility=public)") (targetattr != "userPassword") (version 3.0; acl "Make public objects visible to all"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) Asbefore,thechangeownpasswordACIiscopiedinfromthedefaultset: dn: dc=example,dc=org changetype: modify add: aci aci: (targetattr = "userPassword") ( version 3.0; acl "allow password self modification"; allow (write) userdn = "ldap:///self";) Thevalueofthemacrofacilitybecomesevidentwhencontrollingaccessto nonpublicentriesindepartments.ThetargetURLcontainsthestring ($dn)whichmatchesallentriesinthetreeunderdc=example,dc=org andsavesthematchedstring.Thematchedstringisthensubstitutedinto theuserDNusing[$dn]toidentifyusersinthesamedepartmentasthe entrybeingaccessed.Theuseofsquarebracketsinthesubstitutionmeans thatthematchedstringisfirsttriedwhole,andcomponentsarerepeatedly removeduntilamatchisfoundorthestringisempty.Thisallowstheruleto applytoanentiresubtree.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page27of44

dn: dc=example,dc=org changetype: modify add: aci aci: (target = "ldap:///($dn),dc=example,dc=org") (targetscope = "subtree") (targetattr != "aci || userPassword") (version 3.0; acl "Users may see entries in their own department"; allow (read, compare, search) (userdn = "ldap:///dc=people,[$dn],dc=example,dc=org??sub?") ;) ThisACLpassesallthetestsinthetestsuite. 10.3.3ACLsforIBMTDS TDSdoesnothaveACLmacrossowehavetofindanotherwaytogiveusers accesstoentriesintheirowndepartment.Thefirstjobistocreatea dynamicgroupforeachdepartment: dn: cn=users,dc=groups,dc=a,dc=example,dc=org changetype: add objectclass: groupOfURLs objectclass: ibm-dynamicGroup cn: users memberURL: ldap:///dc=people,dc=a,dc=example,dc=org?? sub?(objectclass=*) dn: cn=users,dc=groups,dc=b,dc=example,dc=org changetype: add objectclass: groupOfURLs objectclass: ibm-dynamicGroup cn: users memberURL: ldap:///dc=people,dc=b,dc=example,dc=org?? sub?(objectclass=*) MembershipofeachgroupisdefinedbyanLDAPsearchURL.Itselectsall entriesinthedepartment'scn=peoplesubtree. ThefirstACIistheusualoneforpublicreadaccess,withafiltertoselect justthoseentriesmarkedwithexampleVisibility=public.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page28of44

dn: dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: access-id:cn=this:(objectclass=*):at.userPassword:grant:w ibm-filterAclEntry: group:CN=ANYBODY: (exampleVisibility=public):normal:rsc ProvidingthelocaldepartmentaccessrequiresoneACIperdepartment. Theyareallverysimilar,withthedepartmentnamesubstitutedinrelevant positions.EachACIgrantsread,searchandcompareaccesstoa departmentalsubtree,usingthedynamicgrouptoselecttheuserswho shouldhaveaccess: dn: dc=a,dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: group:cn=users,dc=groups,dc=a,dc=example,dc=org: (objectclass=*):normal:rsc dn: dc=b,dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: group:cn=users,dc=groups,dc=b,dc=example,dc=org: (objectclass=*):normal:rsc TheACLpassesallthetestsinthetestsuite,butitbreaksanumberof designprinciples.EverydepartmentneedsaspecialgroupanditsownACI, andbothoftheseneedtobecreatedwheneveranewdepartmentisadded.A templatingsystemcoulddothejob,butitdoesmeanthatadministrative userscannotuseLDAPdirectlytomanagedepartments. Anorganisationwithhundredsofdepartments(oraserviceproviderwith thousandsofcustomers)wouldendupwithaverylargesetofACLs.This wouldbeaproblemifaglobalpolicychangewererequired,andmayhavea performanceimpact.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page29of44

10.3.4ACLsforOpenLDAP Theuseofregularexpressionsallowsforaveryelegantsolutionhere. Thefirstdirectiveistheusualonetoallowauthenticationandtopermit userstochangetheirownpasswords. access to dn.subtree="dc=example,dc=org" attrs="userPassword" by self =w by * auth Publicaccessentriesaresimplyhandledbyafilterrule: access to filter="(exampleVisibility=public)" by * read Aregularexpressionselectsentriesinsidedepartmentsandgivesaccessto theappropriatelocalusers: access to dn.regex="(dc=[^,]+,dc=example,dc=org)$" by dn.subtree,expand="dc=people,$1" read by * break Finally,adefaultdenyruletakescareofeverythingelse: access to * by * none Theregularexpressionisworthlookingatinmoredetail.ItactsontheDN oftheentrybeingconsidered.Thereisa$toanchortheendofthepattern, butno^toanchorthestart.Insidetheparenthesesisapatternthat matchesexactlyonelevelofentriesnameddc=.Thismeansthatthe patternwillmatchanyofthesenames:

dc=a,dc=example,dc=org dc=people,dc=a,dc=example,dc=org uid=a1,dc=people,dc=a,dc=example,dc=org dc=groups,dc=a,dc=example,dc=org cn=clerks,dc=groups,dc=a,dc=example,dc=org

ItwillcausetheDNofthedepartmententrytobesavedas$1(thatiswhat theparenthesesarefor). Thebyfieldisnowabletoconstructadefinitionforthesetofuserswho mayreadtheentriesmatchedbythepattern.dn.subtree,expandmeans thatthevaluesavedin$1willbesubstitutedintothestringwhichwill thenbeusedasasubtreespecification.Thusfortheexampleentriesabove,

anyuserinthesubtreedc=people,dc=a,dc=example,dc=orgwillbe grantedreadaccess.OtherusersincludingANONarelefttolaterrulesby theby * breakfield. Strictlyspeaking,thereisariskintheregularexpression:itwillalsomatch entrieswheretheRDNattributenameendswithdcsotheremightbe othersthatarenotdomaincomponentnames.Thiscouldbefixedwitha littleextracomplexity. TheACLpassesallofthetestsinthetestsuite.

10.4DelegatedAdministrationofUsersandGroups
AnorganisationwiththesameDITstructureusedin10.3abovewantsto givelocaladministrativepowertoagroupofclerksineachdepartment.For simplicity,allentrieshavepublicreadaccess. Thisisthelocaladminsexampleinthedistributionpack.

dc=example,dc=org

dc=a

dc=b

dc=people

dc=groups

dc=people

dc=groups

uid=a1

uid=a2

cn=clerks

uid=b1

uid=b2

cn=clerks

Figure4:DelegatedAdministration

Theprinciplesareverysimilar,butthistimewearegrantingwriteaccess, andthesubjectsaredefinedingroups.Inthetests,usera1isamemberof thedepartmentAclerksgroupandb1isamemberofthedepartmentB clerksgroup.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page31of44

10.4.1Tests

Authenticateasusersa1,a2,ANON Checkthatalluserscanreadeachtypeofentry Checkthata1cancreateandmodifyentriesindepartmentA Checkthata1cannotcreateormodifyentriesindepartmentB Checkthata2cannotcreateormodifyentriesineitherdepartment

10.4.2ACLsforSun/Netscapeservers TheusualuserPasswordandpublicitemACIsareused.TheinterestingACI istheonecontrollingtheclerks'access: dn: dc=example,dc=org changetype: modify add: aci aci: (target = "ldap:///dc=people,($dn),dc=example,dc=org") (targetfilter = "(|(objectclass=person)(objectclass=account))") (targetattr = "cn || sn || uid || description || userPassword || objectclass") (version 3.0; acl "Clerks may add and modify users in their own department"; allow (write, add, delete) (groupdn = "ldap:///cn=clerks,dc=groups,[$dn],dc=example,dc=org") ;) Asinthepreviousexample,thetargetDNisselectedbyanLDAPURL containingamacro($dn).Objectclassesandattributesarelimited,andthe clerksgroupisgivenaccessusingamacrosubstitution. TheACLspassmostofthetests,butareunabletopreventtheclerksfrom creatingentrieswithunwantedauxiliaryobjectclassesandattributes.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page32of44

10.4.3ACLsforIBMTDS Asinthepreviousexample,thelackofmacrosandregularexpressions meansthateachdepartmentneedsitsownACLs.Thisistheonethatgives theclerksgroupindepartmentAaccesstocreateandmodifypersonentries: dn: dc=people,dc=a,dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: group:cn=clerks,dc=groups,dc=a,dc=example,dc=org: (objectclass=organizationalUnit):object:grant:a ibm-filterAclEntry: group:cn=clerks,dc=groups,dc=a,dc=example,dc=org: (|(objectclass=account)(objectclass=person)): object:grant:d:normal:rwsc:at.userPassword:grant:w Asinexample10.2above,theACLsgivetheclerksenoughaccesstodotheir jobs,butTDSdoesnotcontrolthecontentoftheentriesthattheyadd. 10.4.4ACLsforOpenLDAP Ihaveincludedthecompletesetofaccessdirectivesheretoillustrate anotherstyle.TheearlierexamplesusedmatchanddefineACLs,where thisoneusestheaccumulatepermissionsstyle.Thebasicdifferenceis thateachaccessdirectiveaddssomethingtothepermissionsandallows controltodropthroughsoalldirectivesareinvolvedinalldecisions. ThisexampledoesnotuseDITContentRules;itcontrolsentrycontent directlyintheACLs,sotheadd_content_acldirectiveisessential. add_content_acl yes Thefirstaccessdirectivedealswithclerkscreatingnewpersonentries.It appliesonlytothechildrenattributeofthedc=peopleentry.Notetheuse of+wtoaddwritepermissionwhileleavingothersalone,andthebreak controltoallowexecutionoftheACLtocontinueatthenextdirective. TheDNisselectedbyaregularexpressionsothatpartofitcanbeusedto definethegroupthatisbeinggivenaccess. access to dn.regex="^dc=people,(dc=[^,]+,dc=example,dc=org)$" attrs="children" by group/groupOfNames/member.expand= "cn=clerks,dc=groups,$1" +w break by * break

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page33of44

Clerkaccesstotheactualentriesunderdc=peopleiscontrolledbythenext directive.TheDNisagainselectedbyregularexpression,butwealsolimit thisruletothedesiredobjectclassesandattributes. Theattributedefinitionisinteresting:itcontainsthepseudoattribute entryandalsothreeobjectclasses.Theeffectisthattheruleonlypermits clerkstowriteattributesthatappearinoneofthoseclasses.Thiscontrolis notasstrongasaDITContentRuleasitcannotpreventtheadditionof auxiliaryclasses(thoughitdoespreventtheadditionofanyextraattributes thattheymightallow). Again,accessisgivenby+wandexecutioncontinueswiththenext directive. access to dn.regex="^[^,]+,dc=people,(dc=[^,]+,dc=example,dc=org)$" filter="(|(objectClass=inetOrgPerson) (objectClass=account))" attrs= "entry,@inetOrgPerson,@account,@simpleSecurityObject" by group/groupOfNames/member.expand= "cn=clerks,dc=groups,$1" +w break by * break Therulesforthedc=groupssubtreesareverysimilar: access to dn.regex="^dc=groups,(dc=[^,]+,dc=example,dc=org)$" attrs="children" by group/groupOfNames/member.expand= "cn=clerks,dc=groups,$1" +w break by * break access to dn.regex="^[^,]+,dc=groups,(dc=[^,]+,dc=example,dc=org)$" filter="(objectClass=groupOfNames)" attrs="entry,@groupOfNames" by group/groupOfNames/member.expand= "cn=clerks,dc=groups,$1" +w break by * break TreatmentoftheuserPasswordattributeisslightlydifferentinthisstyle: usersaregivenwriteandauthenticateaccess,andeveryoneelseisjust givenauthenticate.ItisimportanttoallowANONtoauthenticateasall sessionsstartoffanonymous!

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page34of44

access to attrs="userPassword" by self +wx break by * +x break AswehavenotexplicitlyblockedreadaccesstotheuserPasswordattribute wemustbeverycarefulaboutwhatwedoallowtoberead.Inthespiritof thedefaultdenystyle,thenextdirectivegivesglobalreadaccesstoavery shortlistofattributes.Infacttheaccessgivenis+rscxdwhichpermits read,search,compare,authenticate,anddiscloseonerror. access to * attrs= "entry,objectclass,dc,uid,cn,sn,o,ou,description,member" by * +rscxd break Attheendofthelistisadirectivethatjuststopstheexecutionandusesthe accumulatedpermissions: access to * by * stop

10.5DetailedControlofAttributeandEntryVisibility
WiththesameDITstructureas10.3and10.4above,thisexample demonstratestheuseofvisibilityattributesforentriesinconjunctionwith ruleslimitingthesetofattributesvisibletodifferentrequesters. EntryvisibilityisdefinedbytheexampleVisibilityattribute,usingoneof thesevalues:

internettheentryisvisibletoeveryoneincludinganonymoususers. userstheentryisvisibletoauthenticatedusers. departmenttheentryisvisibletousersinthesamedepartment. Anyothervalue(ornoneatall)theentryisonlyvisibletotheuser thatitrepresents. Anonymoususerscansee:cn,sn,displayname,mail,uniqueIdentifier Authenticateduserscanalsosee:telephoneNumber Samedepartmentuserscanalsosee:uid Userscanalsoseetheirown:descriptionandexampleVisibility

Attributevisibilityforpersonentriesisdefinedbythepolicy:

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page35of44

InorganizationandorganizationalUnitentries,thefollowingattributesare visibletoanyonewhocanseetheentryitself:objectclass,o,ou,dc, description. Thisisthesubsetvisibilityexampleinthedistributionpack. 10.5.1Tests Thispolicydoesnotdefineanywritepermissions,butitstillneedsalotof testsforthevariouscombinationsofreadpermission. Fourpersonentriesarecreatedacrosstwodepartments,andeachisgivena differentexampleVisibilityvalue.Accesstoeachentryisthentestedusing:

Anon Auserintheotherdepartment Auserinthesamedepartment Theuserrepresentedbytheentry

Whiletestingcombinationswherethesubjectshouldnotseetheobject,a furthertestfordetectabilityisincluded.ThistestswhethertheACLsprevent thesubjectfromusingerrormessageanalysistodetectwhethertheentry exists. 10.5.2ACLsforSun/Netscape Thisfamilyofserversdoesnotexplicitlycontrolaccesstoentries:anentryis visibleifanyofitsattributesarevisible. ThedesignofthissetofACLsassumesthatthesuffixentry dc=example,dc=orgismarkedwithexampleVisibility=internet,andit combinesorganisationalandpersonalentriesineachruleonthebasisthat theattributesetsdonotoverlap. ThefirstACIsetstheminimumlevelofaccessforpublicentries: dn: dc=example,dc=org changetype: modify add: aci aci: (targetfilter = "(exampleVisibility=internet)") (targetattr = "cn || sn || displayname || mail || uniqueIdentifier || objectclass || o || ou || dc") (version 3.0; acl "Make public attributes visible to all"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) Authenticatedaccessallowsaslightlylargersetofattributes.Italsopermits accesstoentriesmarkedforusersvisibility.
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page36of44

dn: dc=example,dc=org changetype: modify add: aci aci: (targetfilter = "(|(exampleVisibility=internet) (exampleVisibility=users))") (targetattr = "telephoneNumber || cn || sn || displayname || mail || uniqueIdentifier || objectclass || o || ou || dc") (version 3.0; acl "Make public objects visible to all"; allow (read, compare, search) (userdn = "ldap:///all") ;) Samedepartmentusershavealargersetofattributesandrequireamacro toidentifythem: dn: dc=example,dc=org changetype: modify add: aci aci: (target = "ldap:///($dn),dc=example,dc=org") (targetfilter = "(|(exampleVisibility=internet) (exampleVisibility=users) (exampleVisibility=department))") (targetattr = "uid || telephoneNumber || cn || sn || displayname || mail || uniqueIdentifier || objectclass || o || ou || dc") (version 3.0; acl "Users may see exampleVisibility=dept entries in their own department"; allow (read, compare, search) (userdn = "ldap:///dc=people,[$dn],dc=example,dc=org??sub?") ;)

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page37of44

Userscanalwaysseetheirownentry,butthesetofattributesisstilllimited: dn: dc=example,dc=org changetype: modify add: aci aci: (targetattr = "description || exampleVisibility || uid || telephoneNumber || cn || sn || displayname || mail || uniqueIdentifier || objectclass || o || ou || dc") (version 3.0; acl "Users may see their own entries entries"; allow (read, compare, search) (userdn = "ldap:///self") ;) ThissetofACLspassesmostofthetestsinthetestsuite,butitfailsto preventnonvisibleentriesfrombeingdetected. ThelackofexplicitcontrolonaccesstoentriesmeansthateachACImust dealwithcompletesetsofattributesratherthaneachaddingsome permissions.Thisisclumsy,butatleastwedonotrequireoneACIforeach principal/accesscombination. 10.5.3ACLsforIBMTDS Asusual,themainproblemisdealingwiththesamedepartmentpartsof thepolicy.ThisrequiresonedynamicgroupandoneACLperdepartment. HerearethedynamicgroupsfordepartmentsAandB: dn: cn=users,dc=groups,dc=a,dc=example,dc=org changetype: add objectclass: groupOfURLs objectclass: ibm-dynamicGroup cn: users memberURL: ldap:///dc=people,dc=a,dc=example,dc=org?? sub?(objectclass=*) dn: cn=users,dc=groups,dc=b,dc=example,dc=org changetype: add objectclass: groupOfURLs objectclass: ibm-dynamicGroup cn: users memberURL: ldap:///dc=people,dc=b,dc=example,dc=org?? sub?(objectclass=*) Mostofthepolicyforattributeandentryvisibilitycanbehandledinasingle ACLatthetopoftheDIT.TDSdoesnotexplicitlycontrolreadaccessto
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page38of44

entries:anentryisvisibleiftherequestinguserisallowedtoseetheRDN attribute. TheACIfororganizationandorganizationalUnitentriesisfairlysimple, thoughIhavebeenlazyhereandusedthenormalattributeclassrather thanlistingtheexactattributesthatthepolicyallows. dn: dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: group:CN=ANYBODY: (&(exampleVisibility=internet) (|(objectclass=organization) (objectclass=organizationalUnit))):normal:rsc TheACLcontinueswithitemsdealingwiththesimplercasesofaccessto personentries.Eachruleliststhecompletesetofattributesavailabletothe classofusermakingtherequest.Wecannotusetheaccumulate permissionsstylehere,astheruleshaveconditionsonboththeuserand thevisibility. ibm-filterAclEntry: group:CN=ANYBODY: (&(exampleVisibility=internet)(objectclass=person)): at.objectclass:grant:rsc:at.cn:grant:rsc: at.sn:grant:rsc:at.displayname:grant:rsc: at.mail:grant:rsc:at.uniqueIdentifier:grant:rsc ibm-filterAclEntry: group:CN=AUTHENTICATED: (&(|(exampleVisibility=internet) (exampleVisibility=users)) (objectclass=person)): at.objectclass:grant:rsc:at.cn:grant:rsc: at.sn:grant:rsc:at.displayname:grant:rsc: at.mail:grant:rsc:at.uniqueIdentifier:grant:rsc: at.telephoneNumber:grant:rsc ibm-filterAclEntry: access-id:CN=THIS: (objectclass=person): at.objectclass:grant:rsc:at.cn:grant:rsc: at.sn:grant:rsc:at.displayname:grant:rsc: at.mail:grant:rsc:at.uniqueIdentifier:grant:rsc: at.telephoneNumber:grant:rsc:at.uid:grant:rsc: at.description:grant:rsc: at.exampleVisibility:grant:rsc: at.userPassword:grant:w TocompletethejobweneedtoaddperdepartmentACIstoimplementthe localdepartmentaccesspolicy.
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page39of44

dn: dc=people,dc=a,dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: group:cn=users,dc=groups,dc=a,dc=example,dc=org: (&(|(exampleVisibility=internet) (exampleVisibility=users) (exampleVisibility=department)) (objectclass=person)): at.objectclass:grant:rsc:at.cn:grant:rsc: at.sn:grant:rsc:at.displayname:grant:rsc: at.mail:grant:rsc:at.uniqueIdentifier:grant:rsc: at.telephoneNumber:grant:rsc:at.uid:grant:rsc dn: dc=people,dc=b,dc=example,dc=org changetype: modify replace: ibm-filterAclEntry ibm-filterAclEntry: group:cn=users,dc=groups,dc=b,dc=example,dc=org: (&(|(exampleVisibility=internet) (exampleVisibility=users) (exampleVisibility=department)) (objectclass=person)): at.objectclass:grant:rsc:at.cn:grant:rsc: at.sn:grant:rsc:at.displayname:grant:rsc: at.mail:grant:rsc:at.uniqueIdentifier:grant:rsc: at.telephoneNumber:grant:rsc:at.uid:grant:rsc ThissetofACLspassesmostofthetestsinthetestsuite,butitfailsto preventnonvisibleentriesfrombeingdetected.Italsobreaksseveraldesign principlesbyplacingACLsinentriesthatmightbecreatedroutinely.Each ACIcontainsalonglistofattributes,mostofwhicharethesamefromone ACItothenext:thiswouldbehardtomaintainproperlyifthepolicywereto changeinfuture. 10.5.4ACLsforOpenLDAP ForthisexampleIhavechosenthedefaultdenystylewithaccumulating permissions.Thepolicydefinesvaryingaccesslevelsforparticularsetsof attributes,sothefirstjobistodefineobjectclassestorepresenteachset. ThisisnotessentialbutitdoesmaketheACLseasiertoreadandmaintain. Notethattheseobjectclassesarenotintendedtobeusedindirectoryentries theyarejustbeingusedasaconvenientwayofreferringtoasetof attributesinACLs.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page40of44

objectclass ( 1.2.826.0.1.3458854.666.3.1 NAME 'attrsetAnonVisible' DESC 'Attributes visible to anonymous users' AUXILIARY MAY ( objectclass $ cn $ sn $ displayname $ mail $ uniqueIdentifier ) ) objectclass ( 1.2.826.0.1.3458854.666.3.2 NAME 'attrsetUserVisible' DESC 'Attributes visible to authenticated users' AUXILIARY MAY ( telephoneNumber ) ) objectclass ( 1.2.826.0.1.3458854.666.3.3 NAME 'attrsetDeptVisible' DESC 'Attributes visible to same-department users' AUXILIARY MAY ( uid ) ) objectclass ( 1.2.826.0.1.3458854.666.3.4 NAME 'attrsetSelfVisible' DESC 'Attributes visible to self' AUXILIARY MAY ( description $ exampleVisibility ) ) objectclass ( 1.2.826.0.1.3458854.666.3.5 NAME 'attrsetSelfWrite' DESC 'Attributes that users may change in their own entry' AUXILIARY MAY ( userPassword $ exampleVisibility ) ) objectclass ( 1.2.826.0.1.3458854.666.3.6 NAME 'attrsetOrgVisible' DESC 'Attributes that are visible in Organization and OrganizationalUnit entries' AUXILIARY MAY ( objectclass $ o $ ou $ dc $ description ) ) Thefirstgroupofaccessdirectivesdealswithaccesstoentries,thoughit doesnotgrantanyaccesstotheattributescontainedinthem.

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page41of44

Thesuffixentryisgloballyreadable,andaccesstoallotherentriesis controlledbytheexampleVisibilityattribute.Eachpossiblevalueof exampleVisibilityistreatedinturn;theonlycomplexruleistheonedealing withsamedepartmentusers.Usersaregivenwriteaccesstotheirownentry sothattheycanmodifyuserPasswordandexampleVisibility. access to dn.exact="dc=example,dc=org" by * read access to filter="(exampleVisibility=internet)" attrs="entry" by * read access to filter="(exampleVisibility=users)" attrs="entry" by users read by * none access to filter="(exampleVisibility=department)" dn.regex="(dc=[^,]+,dc=example,dc=org)$" attrs="entry" by dn.subtree,expand="dc=people,$1" read by * none access to attrs="entry" by self write by * none Thenextdirectivedealswithaccesstoattributesinorganizationand organizationalunitentries.ItusestheattrsetOrgVisibleclassratherthan listingtheindividualattributes. access to filter= "(|(objectclass=organization) (objectclass=organizationalunit))" attrs="@attrsetOrgVisible" by * read Attributesinpersonentrieshavedifferentvisibilitydependingonwhois askingforthem.Thisrequiresseveraldirectives,andmakesgooduseofthe accumulatepermissionsstyle. access to filter="(objectclass=person)" attrs="@attrsetAnonVisible" by * +rsc break

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page42of44

access to filter="(objectclass=person)" attrs="@attrsetUserVisible" by users +rsc break by * break access to filter="(objectclass=person)" dn.regex="(dc=[^,]+,dc=example,dc=org)$" attrs="@attrsetDeptVisible" by dn.subtree,expand="dc=people,$1" +rsc break by * break access to filter="(objectclass=person)" attrs="@attrsetSelfVisible" by self +rsc break by * break Writeableattributesarehandledbyasimilarrule.NotethatuserPasswordis inattrsetSelfWritebutnotinattrsetSelfVisible,sotheusercansetitbutnot readitback. access to filter="(objectclass=person)" attrs="@attrsetSelfWrite" by self +w break by * break Althoughnotmentionedinthepolicy,wemustgrantauthenticateaccessto userPasswordfortheanonymoususer.Thisisrequiredtosupport authentication. access to filter="(objectclass=person)" attrs="userPassword" by anonymous +x break by * break Thelastdirectivestopstheaccumulationprocessandusestheresult. access to * by * stop ThisACLpassesallthetestsinthetestsuiteincludingtestsfordetectability. Unfortunatelythereisstillasnag.Ifadepartmententryismarkedforlocal visibilityonlythentheentryitselfisindeedprotectedfromanonymous access,butentriesbelowitmarkedforinternetvisibilitystillappearin searchresults.Thisexposestheexistenceofthesupposedlyinvisible department.Thereissomedebateoverwhatthecorrectbehaviourreallyis insuchacase:thiscanonlyberesolvedbygoingbacktothepolicymakers withaspecificexample.
WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page43of44

11References
References
X50088:X.500/ISO95941TheDirectoryOverviewofConcepts,Models andServices,ISO/CCITT,Geneva,1988 X50093:X.500/ISO95941TheDirectoryOverviewofConcepts,Models andServices,ISO/CCITT,Geneva,1993 RFC2251:MWahl,THowes,SKille,LightweightDirectoryAccessProtocol (v3),IETF,1997 RFC2252:MWahl,ACoulbeck,THowes,SKille,LightweightDirectory AccessProtocol(v3):AttributeSyntaxDefinitions,IETF,1997 X50105:X.500/ISO9594,TheDirectory:Models,ITUT,Melbourne,2005 RFC4513:RHarrison(ed),LightweightDirectoryAccessProtocol(LDAP): AuthenticationMethodsandSecurityMechanisms,IETF,2006 RFC4512:KZeilenga,LDAPDirectoryInformationModels,IETF,2006 FINDL05:AFindlay,LDAPSchemaDesign,ProceedingsoftheUKUUGWinter Conference,2005

WritingAccessControlPoliciesforLDAP:AndrewFindlayJanuary2009Page44of44