Ldapsearch in script met variabele user om te binden

[Hero of Time]

Voor het werk ben ik bezig om het een en ander wat makkelijker te maken om onze interne software te deployen. Een van de stappen hiervoor is de overstap van CVS naar SVN. Omdat we een gemengde omgeving hebben van Windows en Linux wordt er gebruik gemaakt van Active Directory voor authenticatie van verschillende systemen, zo dus ook SVN. Maar onze applicatieservers zijn Linux en hebben lokale gebruikers. De server die onze software build en deployed draait op Linux en hier ben ik met Bash bezig om het een en ander te automatiseren.

Wat ik heb:
Whiptail driven vragen die ingevuld worden. Dit zijn ook de gebruikersnaam en wachtwoord voor AD ivm SVN checkout. Het hele gebeuren is in principe klaar, op een punt na: check van gebruiker in AD ivm deployen naar productie (ontwikkelaars mogen dat niet).

Wat ik wil:
Via ldapsearch zoeken of de gebruiker in een bepaalde groep zit en aan de hand hiervan de productieomgeving als optie weergeven of niet. Ik kan dan ook gelijk controleren of de gebruikersnaam en wachtwoord klopt (ldapsearch geeft een error als 't niet kan binden).

Waar ik op vastloop:
De bind die nodig is om AD/LDAP te kunnen doorzoeken vereist een DN. Maar de gebruikers staan niet in dezelfde OU. Ontwikkelaars staan in een andere OU dan de mensen die wel naar productie mogen gaan. Ik wil niet een aparte gebruiker gebruiken voor de initiële bind (om de DN van de gebruiker te vinden), want dat maakt mijn script minder flexibel en vereist een plain text wachtwoord in het script of ldap.conf.

Dus hoe kan ik binden als user met wisselende DNs? De DN van ontwikkelaars is OU=dev,OU=IT,DC=domein,DC=local, die van productie gebruikers eentje hoger. Google geeft mij niet veel hulp hierin, ik krijg geen zinnig antwoord. Ergens een ldap master die 't weet?

[DutchNutcase]

Dit kun je ook door apache laten regelen en controleren voor SVN. Apache kan gewoon in AD opzoeken of iemand überhaupt bekend is (require valid-user), maar ook of iemand in een bepaalde LDAP groep zit. Ik heb het hier ook zo geregeld binnen een vrij grote organisatie met centraal geregelde set AD servers.

Voorbeeld /etc/apache2/sites-available/svn-ssl:

Bash:

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None

                AuthType Basic
                AuthBasicProvider ldap
                AuthName "Login to the SVN server"
                AuthzLDAPAuthoritative on
                AuthLDAPURL "ldap://<adserver.example.com>/dc=<example>,dc=<com>?sAMAccountName?sub?(objectClass=*)" NONE
                AuthLDAPBindDN "CN=<binduser>,OU=Users,DC=<example>,DC=nl"
                AuthLDAPBindPassword <password>

                require ldap-group CN=svn-read,OU=Groups,DC=<example>,DC=<com>
                require ldap-group CN=svn-rw,OU=Groups,DC=<example>,DC=<com>

                SSLOptions +StrictRequire +FakeBasicAuth +ExportCertData
        </Directory>
        CustomLog /var/log/apache2/svn.log "%t %u %{SVN-ACTION}e" env=SVN-ACTION

        <Location /svn>
                DAV svn
                SVNParentPath /locatie/van/repositories
                SVNListParentPath on
                Order Deny,Allow
                Deny from all
                                                                                                                            
                Satisfy Any                                                                                                 
                                                                                                                            
                <Limit GET PROPFIND OPTIONS REPORT>                                                                         
                        require ldap-group CN=svn-read,OU=Groups,DC=<example>,DC=<com>
                        require ldap-group CN=svn-rw,OU=Groups,DC=<example>,DC=<com>
                </Limit>
                <LimitExcept GET PROPFIND OPTIONS REPORT>
                        require ldap-group CN=svn-rw,OU=Groups,DC=<example>,DC=<com>
                </LimitExcept>
        </Location>

Je ziet ook dat ik een groep heb die alleen leesrechten heeft op de repositories en een groep die ook in mag checken in de repositories. Om dit goed te krijgen zul je wel moeten overleggen met je sysadmins, omdat je de structuur van je AD tree moet kennen en je moet een user hebben die de AD kan lezen. Het beste kun je daar een apart functioneel account voor aan laten maken.

Verder heb ik ook nog de bron die ik heb gebruikt bij het opzetten van dit verhaal:
bron

[Hero of Time]

Je begrijpt niet wat ik wil. SVN draait al prima met LDAP authenticatie, maar ik wil juist het builden van de software, wat pas kan als je een SVN co doet, vergemakkelijken. Om een SVN co te doen, moet je aanmelden met je LDAP/AD gebruiker. Hier wil ik juist op controleren via ldapsearch dat het ook het juiste wachtwoord is en in welke AD groep de betreffende gebruiker zit. Ik geef dan wel of niet de productieomgeving weer om naar te deployen en controleer dan ook gelijk of het wachtwoord correct is. Als het wachtwoord niet goed is, zal de check-out falen en dus ook de build. Het heeft dan geen zin om verder te gaan met het script. Apache heeft hier verders niets mee te maken. Bash daarentegen alles. En omdat m'n gebruikers niet in dezelfde OU zitten, wil ik weten hoe ik het binden (om de groep informatie op te halen) als de volledige DN afwijkt. Hmm, misschien dat $user@domein werkt met binden...

[DutchNutcase]

Excuus, dan heb ik je niet goed begrepen. Hoe ik dat via bash zou moeten doen zou ik niet weten. Ik heb een buildbot draaien en alle buildslaves kunnen uitchecken op basis van een IP uitzondering, die hoeven dus niet in te loggen om uit te kunnen checken (via http). Inchecken moet altijd via https en dus met een wachtwoord. Misschien moet ik hier ook nog een keer aan sleutelen. Ik volg je zoektocht dus op de voet.

[Hero of Time]

Ok, net even tijd gehad om te testen, en verdomt, $user@domein. werkt gewoon. Soms kan het zo simpel zijn.