[Projekt] LDAP Server für VoIP mit Asterisk nutzen

[prochmi]

ich bins wiedermal

die möglichkeit mit dem shell backend habe ich wieder verworfen, da man für die komplette konfiguration ein backend schreiben müsste und das is zu aufwendig.(zuerst wollte ich nur den authentication teil in ein shell backend auslagern, das funktioniert leider nicht)

die möglichkeit über ein referral hab ich noch nicht fertig austesten können, da ich ein anderes problem habe:

die authentifizierungsdaten liegen in der form uid=xxx und userPassword=xxx vor (erweiterter posixAccount).

die uid ist natürlich ungleich der extension des users.


mein ansatz:

dn: uid=xxx,ou=accounts,dc=test,dc=com
objectClass: extensibleObject
objectClass: referral
ref: ldap://1.1.1.1/uid=xxx,ou=Users,dc=company,dc=com

dn: cn=1000,ou=accounts,dc=test,dc=com
obejctClass: top
objectClass: oxyPBXAccount
objectClass: oxyPBXAccountSIP
cn: 1000
oxyPBXAccountBaseDN: uid=xxx,ou=accounts,dc=test,dc=com

ich habe anstatt dem referral testweise einfach mal alle attribute die auf dem anderen LDAP sind so direkt angelegt:

dn: uid=xxx,ou=accounts,dc=test,dc=com
userPassword: {SSHA}xxx==
uid: xxx
cn: xxx
uidNumber: 5
gidNumber: 5
homeDirectory: /home/xxx
sn: xxx
objectClass: shadowAccount
objectClass: posixAccount
objectClass: simpleSecurityObject
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person

wenn ich mich jetzt registrieren möchte, dann erhalte ich folgende fehlermeldung:

ldap_loadentry: LDAP RealTime: Could not find any entry dn=uid=xxx,ou=accounts,dc=test,dc=com

obwohl der eintrag sicher da ist.

ich vermute mal das er sich da mit den verschiedenen cn's und uid's nicht mehr auskennt.

wäre das so in der form möglich? bin ich komplett auf dem holzweg?
kann ich das ganz vergessen?


außerdem hab ich noch folgendes problem (wobei ich mir nicht sicher bin ob das mit dem LDAP treiber zusammenhängt:

ich habe in der sip.conf unter [general] etliche attribute konfiguriert die für alle hosts gleich sind. manche davon werden korrekt verwendet (z.B. language=de) und manche anscheinend einfach ignoriert (z.B: host=dynamic).

wenn ich nicht bei jedem UA wieder das host=dynamic in die LDAP konfig reinschreib, läßt er mich nicht registrieren.

[UPDATE]
ich bin gerade draufgekommen, das er mich immer registrieren lässt, egal was ich da als userPassword eingeb.
kann das bitte jemand verifizieren?
[/UPDATE]

mfg,
michael

 

[prochmi]

auch auf die gefahr hin das ich lästig werde, aber ich hab jetzt statt der sache mit dem simpleSecurityObject einfach das realmedPassword das ja auf md5secret gemapped ist verwendet und auch da kann ich immer registrieren.

irgendwie hab ich das gefühl, das die authentifizierung mit dem LDAP treiber überhaupt nicht funktioniert (bzw. einfach immer authentifiziert).

kann das bitte jemand probieren?

mfg,
michael

 

[prochmi]

ok, ich glaub jetzt hab ichs:

der LDAP treiber macht definitiv kein bind um zu authentifizieren => er kann genauso nur mit md5 secret umgehen (also doch kein intelligenter treiber :-( ...was jetzt nicht heißen soll das er schlecht ist).

also das mit dem simpleSecurityObject ist dann natürlich auch sinnlos (außer ich hab irgendwas überhaupt nicht verstanden) und kann mit der geposteten res_ldap.conf von betateilchen auch nicht funktionieren.

er findet kein realmedPassword (das auf md5 gemapped ist) und nimmt daher an, das kein passwort gesetzt ist => man kann immer registrieren

beim md5 passwort das man dann verwendet (in welchem attribut das dann auch drinnsteht entsprechend dem mapping) muß man unbedingt {md5} vorne einfügen!

also mit

echo -n "<user>:<realm>:<secret>" | md5sum

erzeugen und dann mit {md5} vorangestellt reinschreiben.

mfg,
michael

 

[betateilchen]

[persönliche Meinung]

Das was Du hier zusammenschreibst, glaube ich nicht. Leider habe ich im Moment aber nicht die Zeit, mich auch noch um die LDAP Geschichte zu kümmern. Auf jeden Fall bist Du irgendwie auf dem Holzweg, weil das Ganze bei mir damals viel einfacher funktioniert hat. Auch mit der Authentifizierung gegen einen anderen Server.​

[/persönliche Meinung]

 

[prochmi]

hast du damals auch probiert was passiert wenn du ein falsches passwort eingibst?

ich hab bis vor kurzem auch noch geglaubt das es so funktioniert, eben weil er sich immer super registriert hat.

aber immer registrieren lassen (egal welches passwort man verwendet) ist mindestens genauso schlecht wie gar nicht registrieren lassen

du hast mal erwähnt, das du kontakt mit dem entwickler hast, ist das noch der fall?

hat vielleicht jemand anderer zeit dieses verhalten zu verifizieren?
(oder verwendet sonst wirklich niemand den treiber?)


mfg,
michael

 

[betateilchen]

Ja, das mit dem falschen Paßwort hatte ich getestet.

 

[prochmi]

so, und jetzt gehe ich noch weiter

man braucht nicht uid UND cn, sondern nur eins der beiden (als index).
das ist auch der grund wieso es dazu kein mapping gibt.

das ist im prinzip der kontext (die extension selber) in der sip.conf (also das in den []).

wenn man im schema das uid bei MUST wegnimmt und zu MAY dazugibt, kann man sich aussuchen ob man ein uid oder ein cn nimmt.
es funktioniert sowohl mit dem einen als auch mit dem anderen (und man braucht NICHT beide).

wenn ich da falsch liege (was ja durchaus sein kann), wäre es möglich, das du kurz beschreibst wie es deiner meinung nach ist?

also der komplette zusammenhang (mappings, index, extension, username, passwörter,...)

mfg,
michael

 

[prochmi]

so, wir haben jetzt im sourcecode nachgeschaut und es ist definitiv so wie ich es vorher schon vermutet habe:

+) wenn im res_ldap.conf md5secret auf realmedPassword gemapped ist, dann MUSS es auch ein attribut realmedPassword im ldap geben (userPassword bringt gar nix!). wenn nicht => dann kann man auch mit falschem pw registrieren

+) dieser md5hash MUSS aus "<username>:<realm>:secret>" gebildet werden => wenn nicht, dann meldung falsches passwort

+) es MUSS ein {md5} vor dem passwort stehen. wenn nicht => man kann auch mit falschem passwort registrieren

+) wenn man gegen einen anderen ldap authentifizieren möchte, dann MUSS in dem passwort feld dort ebenfalls der md5 - hash genauso gebildet worden sein wie oben


mfg,
michael

 

[cibi]

Ich habe keine Ahnung um was es geht, LDAP kenne ich nicht allzu gut und meine C (ohne ++) Kenntnisse sind eingerostet
=> also ideal um zu Antworten
Du versuchst also einzelne Sipaccounts/Benutzer via LDAP zu registrieren und das ist dein Problem?

So wie ich das sehe, macht der LDAP realtime Treiber folgendes:

- er benutzt die Standard Openldap Lib des Systems
=> kann theoretisch (sofern programmiert) alles was diese auch kann

- er gibt diese Daten mehr oder weniger "nur" an Asterisk weiter, d.h. kann man eventuell mal von Hand eine sip.conf Datei mit dem entsprechendem Eintrag erstellen und schauen ob es funktioniert.

Edit: entfernt, machte keinen Sinn.


-----------------------------------
PS:
Wenn man vielleicht nicht mit der C Lib testen will, kann man z.B. auch den Python Wrapper benutzten, geht sogar unter Windows:
http://python-ldap.sourceforge.net/
Recht einfach, s. Beispiele, am Besten mit einem Python Editor bearbeiten.
=> so lassen sich eventuell Probleme / Test besser nachvollziehen.

---------------------------------
- noch was anderes: wenn man bei

dbpass=xxx   ; Bind password
dbuser=cn=admin,dc=voip,dc=fh-stpoelten,dc=ac,dc=at; Bind DN

das Passwort leer lässt, wird als Passwort "asterisk" verwendet. (sollte aber als Logmeldung erscheinen).
Wenn man eine anonyme Binding will muss dbuser leer/nicht gesetzt sein.

 

[cibi]

+) wenn im res_ldap.conf md5secret auf realmedPassword gemapped ist, dann MUSS es auch ein attribut realmedPassword im ldap geben (userPassword bringt gar nix!). wenn nicht => dann kann man auch mit falschem pw registrieren

Logisch!?

+) dieser md5hash MUSS aus "<username>:<realm>:secret>" gebildet werden => wenn nicht, dann meldung falsches passwort

Vermutlich deswegen

- er gibt diese Daten mehr oder weniger "nur" an Asterisk weiter, d.h. kann man eventuell mal von Hand eine sip.conf Datei mit dem entsprechendem Eintrag erstellen und schauen ob es funktioniert.

http://voip-info.org/wiki/index.php?page=Asterisk+config+sip.conf
http://voip-info.org/wiki/index.php?page=Asterisk+sip+md5secret

+) es MUSS ein {md5} vor dem passwort stehen. wenn nicht => man kann auch mit falschem passwort registrieren

mhh, in der Funktion

static struct ast_variable *realtime_ldap_entry_to_var(struct ldap_table_config* table_config, LDAPMessage *ldap_entry)

gibt es folgenden Code:

(...)
 int is_realmed_password_attribute=strcasecmp(attribute_name,"md5secret")==0;
(...)
if (is_realmed_password_attribute)
        {
          if (strncasecmp(value,"{md5}",5)==0)
        value+=5;
          else
        value=NULL;
        };

welcher eigentlich das {md5} entfernen sollte.
Falsch, sitzen, 6
ARGR, natürlich muss {md5} gesetzt sein, ansonsten wird das Passwort auf eine NULL Variable gesetzt.
Ich entschuldige mich für den peinlichen Fehler...:blonk:
(entfernt wird das {md5} natürlich schon, nur ohne gehts nicht)

 

[betateilchen]

Hab nochmal in meinem Mail-Archiv zum Thema MD5 gekramt und folgendes gefunden. Das ist alles schon so lange her, und ich mache mir über die Einrichtung einfach keine Gedanken mehr, weil alles funktioniert und ich die gesamte Administration der Asterisk-LDAP Daten über quick&dirty-PHP-Schnipsel aus dem Browser heraus mache.

Be careful about the password:
if you have
[general]
realm=MyRealm

and a password 'MyPassword' for device id: 'MyPhone'

generate the MD5 password like this:
echo -n "MyPhone:MyRealm:MyPassword" | md5sum
and put the resulting string, prefixed by {MD5} in userPassword ldap entry.

 

[prochmi]

Ich habe keine Ahnung um was es geht, LDAP kenne ich nicht allzu gut und meine C (ohne ++) Kenntnisse sind eingerostet
=> also ideal um zu Antworten
Du versuchst also einzelne Sipaccounts/Benutzer via LDAP zu registrieren und das ist dein Problem?

nein, damit hab ich mittlerweile prinzipiell kein problem

nur kann die konfig die betateilchen auf seite 2 gepostet hat so nicht richtig funktionieren.

und die authentifizierung gegen einen anderen LDAP leider auch nicht so wie ich das vorher beschrieben hab (das man also einfach dagegen binded). => leider

So wie ich das sehe, macht der LDAP realtime Treiber folgendes:

- er benutzt die Standard Openldap Lib des Systems
=> kann theoretisch (sofern programmiert) alles was diese auch kann

- er gibt diese Daten mehr oder weniger "nur" an Asterisk weiter, d.h. kann man eventuell mal von Hand eine sip.conf Datei mit dem entsprechendem Eintrag erstellen und schauen ob es funktioniert.

Auch der sip.conf Wert md5secret wird einfach an Asterisk übergeben, es wird lediglich ein eventuell vorhanden Präfix {md5} entfernt.
=> andere Passwort Verschlüsselung wandelt der Treiber daher nicht um
Edit: entfernt, machte keinen Sinn.

richtig.
zu beachten ist: der präfix md5 muß bei ldap dabei sein (bei sip.conf und bei konfig über mysql aber nicht!). das "gefährliche" an der ganzen sache ist, das der treiber bei nichteinhalten dieser regel so reagiert, wie wenn KEIN passwort gesetzt wäre, also einfach immer registrieren lässt!

-----------------------------------
PS:
Wenn man vielleicht nicht mit der C Lib testen will, kann man z.B. auch den Python Wrapper benutzten, geht sogar unter Windows:
http://python-ldap.sourceforge.net/
Recht einfach, s. Beispiele, am Besten mit einem Python Editor bearbeiten.
=> so lassen sich eventuell Probleme / Test besser nachvollziehen.

ähh, was willst du da mit einer C lib oder einem python wrapper testen? versteh ich nicht.


mfg,
michael

 

[cibi]

Kurze Zusammenfassung:
Mann beachte meine xfachen Edits oben

ndas der treiber bei nichteinhalten dieser regel so reagiert, wie wenn KEIN passwort gesetzt wäre, also einfach immer registrieren lässt!

Man könnte eventuell das

  else
        value=NULL;

entfernen. Aber das sollte sich dann jemand doch etwas genauer anschauen und sich das nochmal durch den Kopf gehen lassen.
(Alternative: die Registrierung scheitern lassen)
PS: Das wäre dann doch ein Grund einen Fehlerreport unter
http://bugs.digium.com/view.php?id=5768
zu schreiben.

ähh, was willst du da mit einer C lib oder einem python wrapper testen? versteh ich nicht.

Da du bzw. ihr ja schon den C Code angeschaut habt, dürfte das sich sowie so erledigt haben.
Ich meinte damit lediglich, das man bspw. mit Python und dem zugehörigem LDAP Modul sehr leicht den Zugriff auf den LDAP Server wie ihn Asterisk/realtime_ldap durchführt bzw. durchführen soll nachstellen kann und grundsätzliche Fehler auschließen kann.
Aber das ist hier wohl nicht nötig.

 

[prochmi]

mhh, in der Funktion

static struct ast_variable *realtime_ldap_entry_to_var(struct ldap_table_config* table_config, LDAPMessage *ldap_entry)

gibt es folgenden Code:

(...)
 int is_realmed_password_attribute=strcasecmp(attribute_name,"md5secret")==0;
(...)
if (is_realmed_password_attribute)
        {
          if (strncasecmp(value,"{md5}",5)==0)
        value+=5;
          else
        value=NULL;
        };

welcher eigentlich das {md5} entfernen sollte.
Falsch, sitzen, 6
ARGR, natürlich muss {md5} gesetzt sein, ansonsten wird das Passwort auf eine NULL Variable gesetzt.
Ich entschuldige mich für den peinlichen Fehler...:blonk:
(entfernt wird das {md5} natürlich schon, nur ohne gehts nicht)

genau das mein ich

hab deine ganzen edits nicht mehr rechtzeitig gesehen...

mfg,
michael

 

[prochmi]

Hab nochmal in meinem Mail-Archiv zum Thema MD5 gekramt und folgendes gefunden. Das ist alles schon so lange her, und ich mache mir über die Einrichtung einfach keine Gedanken mehr, weil alles funktioniert und ich die gesamte Administration der Asterisk-LDAP Daten über quick&dirty-PHP-Schnipsel aus dem Browser heraus mache.

wenn es nur meine beobachtungen gewesen wären, dann würd ich mich ja vielleicht von dem quote überzeugen lassen, aber wenn man sich den code anschaut, dann kann es gar nicht sein, das man userPassword verwenden kann wenn das md5secret auf realmedPassword gemapped ist.

[edit]@betateilchen: wenn du die konfig so im einsatz hast, brauchst du doch nur das passwort eines clients verändern und schaun ob er sich trotzdem registrieren kann[/edit]

mfg,
michael