Slim Active Directory repliceren met behulp LDAP

[Boudewijn]

Hoi


Ik wil voor een authenticatie server graag een Active Directory replicatie in LDAP plaats laten vinden. Dit omdat ik op het systeem zelf een stukje redundantie plaats moet gaan vinden, en er ook bepaalde informatie (wat met betrekking tot billing, en wat locale eigenschappen) in een LDAP structuur opgeslagen moet worden. Ik wil dus de usernames en (hashes van) passwords uit de AD halen, en die in een LDAP structuur krijgen. Momenteel ben ik bekend met het repliceren van LDAP (als in: ervaring mee).

Echter ben ik daar nu een redelijke tijd over aan het lezen geweest, maar ik kom er totaal niet meer uit. Heb namelijk het idee dat ik in kringetjes aan het draaien ben.

Er is een aantal mogelijkheden, maar ik krjig niet helemaal helder wat er nou precies mee te doen is. Een ervan is het gebruik van NTLM (dat zit in het samba pakket), maar ik krijg het idee dat dit puur bedoeld is als authenticatie methode tegen AD aan. Dus dat NTLM een client is die gewoon kan authenticeren. Wil ik dus niet hebben.

Een andere optie die ik heb gezien om met AD te communiceren is het gebruik van Kerberos, maar ook hier lijkt geen nette LDAP-replicatie mee haalbaar. Ik lees er althans ook niets over.


Heeft iemand hier toevallig ervaring met een dergelijke opstelling? en wat heb je gedaan om er wat moois van te maken?
Ik heb zelf de O Reilly boeken over LDAP, Samba en AD erop nagekeken... weinig info. En ook googlen heeft echt veel opgeleverd maar niet iets waar ik wat mee kan.

[Insano]

Ik heb zelf toevallig recentelijk met een project nog bezig geweest met AD en LDAP, maar dat was dan een apache webproxy welke via mod_authz_ldap authenticeerde tegen AD aan. Werkt wel geinig.

Maar in principe kan je dus gewoon met een LDAP client connecten naar active directory, Dus als je zorgt dat je een bindDN hebt en een basePath, kan je gewoon LDIF uit je AD halen. Welke je weer in je lokale LDAP server propt.

In feite ben je dan gewoon aan het Sync Replicaten.

Overigens kan je trouwens ook nog LDAPs tegen AD gaan praten, maar dan moet je wat truucjes uithalen binnen je AD om dat voor elkaar te krijgen. Maar dat staat vast ergens op de MS knowledge base..

Modbreak:

We houden ons hier niet bezig met trollen naar Microsoft

[ Voor 25% gewijzigd door Pim. op 29-05-2007 19:42 ]

[Boudewijn]

klopt alleen moet ik volgens jouw oplossing dus een client nemen, deze telkens een user op laten halen en dat dan wegschrijven in LDAP.
Dat kan inderdaad, het apparaat gaat mensen toelaten dmv Radius en dan een AD als backend. Nadat ik de user dan tegen de AD heb geauthentificeerd de zaak wegschrijven @ LDAP.


Echter hebben we zelf liever een gewone replicatie waarbij gewoon continue wordt gerepliceerd (evt met alleen hashes van passwords ipv passwords zelf) omdat je dan nog door kunt werken als je AD eruit ligt (hey het is en blijft windows he ).

Ik heb echter naar de bovengenoemde applicaties gekeken, maar kom er eigenlijk niet meer uit met welke tool(kit) ik kan bereiken wat ik hier tracht te bewerkstelligen.

[Insano]

Ah op zo'n manier.. Volgens mij kan je niet met slurpd aan de gang tegen je AD aan.
Wat je wel natuurlijk zou kunnen doen is gewoon een slim perl scriptje schrijven die de ldap query tegen je AD aan doet, welke de juiste info eruit haalt, en daarna in je ldap propt., en dat dan om de X aantal minuten laten draaien.

Want het 'echt' repliceren van AD naar LDAP zoals jij nu beschrijft heb ik nog nooit gezien. Meestal zet men dan gewoon een 2de AD server erbij.

[alt-92]

...Of een simpel doosje waar je ADAM op zet

[Boudewijn]

klopt een extra doosje is leuk, maar helaas niet geschikt.
ons doosje komt bij klanten te staan, en een van de speerpunten is juist het gebruik van de bestaande AD structuur (het is wel leuk als RADIUS dezelfde userbase gebruikt als de bestaande structuren). RADIUS-LDAP authenticatie gaat prima, en het leek ons daarom erg makkelijk om met LDAP te syncen.

De optie van alt-92 valt dus min of meer af (dank je wel trouwens ) .
Insano, ja een perl scriptje is een optie maar kan ik dan ook passwords uitlezen? (jaja moet zo zelf even googlen)

[Insano]

In principe kan je volgens mij gewoon de gehashte versies uit AD halen. Het is wel weer afhankelijk van de ACL's op je AD, wat je precies te zien krijgt. Maar het moet kunnen volgens mij.
Hier heb ik verder (gelukkig) nooit mee hoeven pielen iig..

Als je met ldapsearch op een linux machine gaat querien zie je precies wat je terugkrijgt uit de AD, en afhankelijk daarvan kan je zo een perl scrippie in elkaar draaien.

[ Voor 26% gewijzigd door Insano op 07-05-2007 10:31 ]

[Boudewijn]

Als je met ldapsearch op een linux machine gaat querien zie je precies wat je terugkrijgt uit de AD, en afhankelijk daarvan kan je zo een perl scrippie in elkaar draaien.

Daarbij connect je zoals jij in de 2e post van dit topic hebt beschreven?

offtopic:
Je gelooft het niet, maar ik ben hier al echt best lang mee aan het kloten (voor mijn afstuderen).

[Insano]

Yup.

Zoiets:
ldapsearch -x -h <hostname> -D "<bindDN>" -W -b "<BasePath>" "<zoekfilter>"

Uit de manpage kan je veel info halen.

--edit--
Binnen Perl heb je overigens wel apparte modules welke het mogelijk maken om met LDAP te communiceren, het bovenstaande voorbeeldje is dus alleen om op commandline te rommelen.

[ Voor 135% gewijzigd door Insano op 07-05-2007 11:48 ]

[Boudewijn]

Insano schreef op maandag 07 mei 2007 @ 11:40:
Yup.

Zoiets:
ldapsearch -x -h <hostname> -D "<bindDN>" -W -b "<BasePath>" "<zoekfilter>"

Uit de manpage kan je veel info halen.

--edit--
Binnen Perl heb je overigens wel apparte modules welke het mogelijk maken om met LDAP te communiceren, het bovenstaande voorbeeldje is dus alleen om op commandline te rommelen.

dat van ldapsearch wist i kwel , maar daar staat weinig over AD in de manual.
iig hardstikke bedankt, ik ga het morgen eens uittesten

[Boudewijn]

tijd voor een update.

ik merk dat ik vanaf mijn bak op 2 manieren met de test-AD-setup (waar ik overigens ook gewoon 'root' xs toe heb).

Gewoon zonder username , niet zo handig en met SASL.
Nu heb ik daarstraks in de AD een usertje aangemaakt , genaamd fubar met als password 12345 (password is anders hoor, maar even voor het voorbeeld).

Als ik anoniem (iig zonder username en pass op te geven @ ldapsearch) wil connecten komt hij met een password vraag. Deze kan ik niet beantwoorden, want ik heb niet kunnen vinden of er een 'main' password op die doos is. Mocht dat zo zijn, dan willen we dat natuurlijk ook niet zo in ons product op die manier gaan regelen.


De sasl optie lijkt me netter, dus een user+pass combi. Echter heb ik net proberen te connecten:

code:

boudewijn@servert ~ $ ldapsearch   -h 192.168.50.216  -x -b "dc=domein,dc=com" "*" -U fubar
ldapsearch: incompatible previous authentication choice

Waarom domein.com het domein is dat die AD doos serveert.

Dat is op te lossen door de -x weg te halen (-x --> simple auth).

Echter gaat zodra ik het password van user fubar invoer ldapsearch compleet over de zeik:

code:

boudewijn@servert ~ $ ldapsearch  -h 192.168.50.216 -W -b "dc=domein,dc=com" "*" -U fubar
Enter LDAP Password:
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

Kan iemand me een bump de goede richting in geven? Insano maybe?

[Insano]

Waarom gebruik je optie -U en niet -D?

code:

-D "cn=fubar,dc=domein,dc=com"

* Insano gaat er vanuit dat je fubar als bind account gebruikt.

[ Voor 27% gewijzigd door Insano op 09-05-2007 12:34 ]

[Boudewijn]

Okay dat scheelt al met al een stuk, ook het feit dat ik het goede IP nu heb (bedankt collega die het aangelegd heeft...).
Nog steeds wat issues echter, maar ik kom al verder

code:

boudewijn@servert ~ $ ldapsearch   -h 172.26.50.200   -b "dc=FOO,dc=com" "(objectclass=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Cannot determine realm for numeric host address)

code:

boudewijn@servert ~ $ ldapsearch -Y gssapi -h 172.26.50.200
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Cannot determine realm for numeric host address)

Google leerde mij dat ik een reverse DNS record moest zetten, en dit is ook gedaan.
User [e-mail] is trouwens ook domain administrator-group lid gemaakt.

[Insano]

code:

ldapsearch -x -h 172.26.50.200 -D "cn=fubar,dc=FOO,dc=com" -b "dc=FOO,dc=com" "(objectclass=*)"

Dit zou moeten werken, je geeft een Host op, een BindDN (optie -D), een BasePath (optie -b), en een zoekfilter. Er vanuit gaande dat je fubar user gewoon onder FOO zit.
Als je fubar user ook nog in een folder "users" zit, dan word het anders:

code:

ldapsearch -x -h 172.26.50.200 -D "cn=fubar,ou=users,dc=FOO,dc=com" -b "dc=FOO,dc=com" "(objectclass=*)"

Dus ou=users er nog bij in de bindDN, bij mij was het overigens geen OU, maar een CN. Moet je even in je AD kijken wat voor type mapje het is, een OrganisationalUnit (OU) of een normaal kaal mapje, dan word het een CommonName (CN) eg: cn=users,dc=FOO,dc=com.

Zelf gebruik ik -x voor simple authentication (van de BindDN), probeer dat eerst aan de praat te hebben voor je gaat rommelen met SASL

[ Voor 42% gewijzigd door Insano op 10-05-2007 18:11 ]

[Boudewijn]

ik weet inderdaad die parameters van ldapsearch, maar ik zit dus met het probleem dat ik niet helemaal weet (helemaal niet) hoe ik nou moet connecten met AD.

LDAP snap ik helemaal ondertussen (afaik dan ) zolang het simpel querien en repliceren en slapadden is. Echter vind ik de AD-informatie bij tijd en wijlen erg schamel op dit gebied.

[Boudewijn]

zo, weer eens een gezellige kick.

ik krijg de zaak nog steeds niet gebind, maar is dit wel de weg om op te gaan als ik wil repliceren?
Reden: AD is ook 'gewoon' een vorm van LDAP. Daar zou toch replicatie tussen mogelijk moeten zjin?

ik doe dit btw:

code:

boudewijn@servert ~ $ ldapsearch -x -h 172.26.50.200 -D "cn=fubar,ou=users,dc=lumiad,dc=com" -b "dc=lumiad,dc=com" "(objectclass=*)"
# extended LDIF
#
# LDAPv3
# base <dc=lumiad,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 1 Operations error
text: 00000000: LdapErr: DSID-0C0905FF, comment: In order to perform this ope
 ration a successful bind must be completed on the connection., data 0, vece

In de AD ligt onder 'Users' een user met als type 'User' (doh). Het account is trusted for delegation en heeft geen pre-kerberos auth nodig.

Hij is lid van:
domein admins, domain users en remote desktop users


Iemand ziet mijn fout?

[Boudewijn]

okay we zijn er weer eens verder mee aan het gaan. Ik gebruik nu -W om het password te laten vragen. en heb een schone AD install gedaan (huidige was kennelijk ergens vervuild).


Nu heb ik een user aangemaakt, en ik wil eigenlijk de usernames+passwords in de lokale LDAP opslaan.

Maar in principe kan je dus gewoon met een LDAP client connecten naar active directory, Dus als je zorgt dat je een bindDN hebt en een basePath, kan je gewoon LDIF uit je AD halen. Welke je weer in je lokale LDAP server propt.

In feite ben je dan gewoon aan het Sync Replicaten.

Overigens kan je trouwens ook nog LDAPs tegen AD gaan praten, maar dan moet je wat truucjes uithalen binnen je AD om dat voor elkaar te krijgen. Maar dat staat vast ergens op de MS knowledge base..

Als ik dit zo lees zou ik bij het password van mijn AD users (welliswaar in hash vorm) moeten kunnen. Ik krijg dit echter niet voor elkaar.


Weet iemand hoe dit zit? Directe replicatie zal niet gaan lees ik overal, maar ik wil wel graag de username+password uit kunnen lezen (username lukt, password mag dus hashed) zodat ik er lokaal ook tegen authenticeren.

Dit kan zowel op een push-methode (zodra de AD iets verandert een update naar de LDAP pushen) of handmatig pullen (cronjob+scriptje). pushen heeft voorkeur btw, maar ik vind er heel weinig over.

[Alex)]

Maak je verbinding via LDAP of via LDAPS? Als ik het me goed herinner heb je LDAPS nodig om bij password-gegevens te kunnen...

[Boudewijn]

gewoon LDAP.

heb je daar mischien een bron van? (nofi maar veel mensen roepen dingen, terwijl er vrij weinig feiten bekend zijn over een aantal zaken).

@Alex (edit): heb jij het over LDAPS of TLS over LDAP?
LDAP-ssl is deprecated volgens de ldap faq.

[ Voor 26% gewijzigd door Boudewijn op 11-07-2007 13:06 ]

[Alex)]

Ik was toen bezig met AD en PHP via LDAP, daarvoor wilde ik de adLDAP-class gebruiken, daar vond ik een pagina over LDAP over SSL. Daar staat dat je LDAPS voor password-related dingen nodig hebt...

[ Voor 18% gewijzigd door Alex) op 11-07-2007 13:07 ]