Koppeling van LDAP entry met database

[alienfruit]

Wat is de beste manier om een LDAP entry te koppelen aan een database record? Ik weet niet wat hiervoor de best practices zijn. Kan ik hiervoor de commonName attribute gebruiken? Ik wil namelijk reeks data van een database exporteren naar LDAP alleen wil ik nog wel op een gemakkelijke manier de record weer kunnen terugvinden om waar nodig aan te passen.

Er zijn een hele reeks object classes met bijhorende attributes te vinden. Bijv. commonName of uid. Maar wat is de beste? De externe partij maakt iig geen gebruik van commonName want het wordt niet gebruikt voor weergave (wel displayName)

[ Voor 10% gewijzigd door alienfruit op 07-02-2011 09:25 ]

[Rigi]

Ik zou voor UID kiezen als ik de keuze had. De rest is volgens mij in principe 'gebruikers input' en daarmee redelijk onbruikbaar als identifier.

[Onno]

Het lijkt me het meest voor de hand liggen om de DN op te slaan: die is per definitie altijd uniek.

[Bene]

Een UID kan op meerdere plaatsen in de LDAP boom voorkomen, een DN verandert als de locatie van een LDAP entry verhuist. Da's beide exotisch, maar als het in jouw geval wel relevant is kun je het GUID of de ENTRYUUID gebruiken - dat zijn "operational attributes", zaken die wel bestaan maar alleen worden getoond indien expliciet aangegeven in de LDAP query.

Edit: dom. Slecht gelezen, data moest in LDAP ipv database.

[ Voor 8% gewijzigd door Bene op 07-02-2011 09:52 . Reden: Vraag slecht gelezen. ]

[alienfruit]

Bedankt! Ik ga voorlopig voor het uid veld en sla daar de record id van de database record in op. Maakt het makkelijk om de record op te zoeken voor updates.

code:

uid=p123,ou=adresboek,dc=bedrijf,dc=nl

Nou ja, p123 (persoon) of c456 (bedrijf)

[ Voor 23% gewijzigd door alienfruit op 07-02-2011 10:56 ]

[alienfruit]

Jammer, dat je de attribuut 'country' of 'c' niet kan gebruiken

[ViNyL]

alienfruit schreef op maandag 07 februari 2011 @ 11:43:
Jammer, dat je de attribuut 'country' of 'c' niet kan gebruiken

Hoe bedoel je dat? Je kan in feite alle attributen gebruiken maar niet alles zul je in het AD console zien.

Als je een volledig overzicht wil van alle velden die er zijn kun je in het AD console het AD schema eens bekijken. Er zijn een hoop velden waar niets mee gedaan wordt, maar wel beschikbaar zijn. Wel moet je natuurlijk uitkijken met velden waarin Outlook of Exchange zaken mee doet.

[ Voor 32% gewijzigd door ViNyL op 07-02-2011 11:46 ]

[Onno]

AD? Exchange? Niet iedereen die wat met LDAP doet gebruikt Windows...

[alienfruit]

Nou ik gebruik in de iNetOrgPerson object class maar die heeft geen country en als ik in mijn LDIF zowel de klassen: inetOrgPerson én country specificeer dan krijg ik een foutmelding terug van OpenLDAP.

[NMe]

Het hangt ook een beetje van de applicatie af. Voor de AD-integratie in ons intranet maakt ik gebruik van de CN aangezien ik op basis daarvan het makkelijkst accounts kan matchen terwijl ik veilig de aanname kan maken dat dezelfde naam niet op andere plekken in de tree problemen gaat leveren. Afhankelijk van beperkingen waarmee je te maken hebt kan het zinniger zijn om naar meer unieke attributen te kijken.

[Onno]

alienfruit schreef op maandag 07 februari 2011 @ 12:07:
Nou ik gebruik in de iNetOrgPerson object class maar die heeft geen country en als ik in mijn LDIF zowel de klassen: inetOrgPerson én country specificeer dan krijg ik een foutmelding terug van OpenLDAP.

country is een structural class, net als inetOrgPerson. Je kunt alleen auxiliary classes toevoegen aan een object van een bepaalde structural class, tenzij de class die je wilt toevoegen een super/subclass van die structural class is.

Je kunt overigens ook gewoon zelf een nieuwe auxiliary class definieren met een eigen attribuut voor deze gegevens, dan weet je zeker dat het nergens mee botst.

[alienfruit]

Het is voor het opslaan van de klantengegevens zodat de telefooncentrale en SIP telefoons mooi de bellende partij kan weergeven. Nu dacht ik dan kan ik het meteen gebruiken als echt adresboek. Alleen nu loop ik dus tegen het probleem aan dat inetOrgPerson geen land attribuut heeft.

Ik heb nu eigenlijk een update hook geschreven voor de CRM van het intranet die vervolgens de adresboek items aanpast. Ik gebruik nu het veld uid voor het opslaan van de record id van de CRM. Zodat ik in de hook makkelijk kan controleren of de item al bestaat of niet.

Volgens mij zou het mooiste zijn dat ik een nieuwe client en company klasse aanmaak hiervoor. Toch?

[ Voor 26% gewijzigd door alienfruit op 07-02-2011 12:21 ]

[Verwijderd]

Je zou met de Perl en het module Net::LDAP en DB::Oracle een interface kunnen bouwen mocht je daar sterk in zijn.

[alienfruit]

Ja, ik heb nu een hook voor de CRM die LDAP update na een save actie in de CRM. Dit begint al te werken.
Bedoel je dit met Net::LDAP en DB::Oracle of iets anders?

[Verwijderd]

alienfruit schreef op maandag 07 februari 2011 @ 12:46:
Ja, ik heb nu een hook voor de CRM die LDAP update na een save actie in de CRM. Dit begint al te werken.
Bedoel je dit met Net::LDAP en DB::Oracle of iets anders?

Wat ik bedoelde was dat je met DB::Oracle dan die gegevens opvraagt en dan deze in LDAP zet dmv Net::LDAP.

[alienfruit]

Aah ja, zo'n soort oplossing heb ik nu ook. De CRM ondersteund hooks bij het wijzigen van klantengegevens. Bij elke wijziging wordt het record geüpdatet in LDAP directorie. Het lijkt redelijk stabiel te werken...