Personal tools
HylaFAX The world's most advanced open source fax server

Difference between revisions of "User talk:Atlantex"

(Hylafax - Active Directory Konfiguration)
 
Line 15: Line 15:
 
- PAM Authentivizierung (Linux Maschinen Accounts) zum laufen bringen.
 
- PAM Authentivizierung (Linux Maschinen Accounts) zum laufen bringen.
  
Zuerst sollte man prüfen ob PAM Support in der Hylafax Installation eingebunden ist, dies prüfen wir mit folgendem Befehl:
+
Zuerst sollte man prüfen ob PAM Support in der Hylafax Installation eingebunden ist, dies prüfen wir mit folgendem Befehl:<br><br>
  
ldd /usr/sbin/hfaxd
+
ldd /usr/sbin/hfaxd<br><br>
  
wenn etwas wie
+
wenn etwas wie<br><br>
  
libpam.so.0 => /lib/libpam.so.0 (0xb7f02000)  
+
libpam.so.0 => /lib/libpam.so.0 (0xb7f02000)<br><br>
  
aufgelistet wird, ist der PAM Support mit eingebunden, wenn nicht dann bitte eine aktuellere Version inkl. PAM Support installieren oder manuell den PAM Support einkompilieren.
+
aufgelistet wird, ist der PAM Support mit eingebunden, wenn nicht dann bitte eine aktuellere Version inkl. PAM Support installieren oder manuell den PAM Support einkompilieren.<br><br>
  
 
Als nächstes legen wir einen Testuser im Linux System an,
 
Als nächstes legen wir einen Testuser im Linux System an,
adduser testuser und bitte auch ein Passwort vergeben.
+
adduser testuser und bitte auch ein Passwort vergeben.<br><br>
  
Nun die Datei /etc/pam.d/hylafax wie folgt editieren und falls notwendig erstellen:
+
Nun die Datei /etc/pam.d/hylafax wie folgt editieren und falls notwendig erstellen:<br><br>
  
auth        sufficient    pam_unix.so debug
+
auth        sufficient    pam_unix.so debug<br>
account  sufficient    pam_unix.so debug
+
account  sufficient    pam_unix.so debug<br>
session  sufficient    pam_unix.so debug
+
session  sufficient    pam_unix.so debug<br><br>
  
Das debug kann später entfernt werden, zeigt aber jetzt möglich Fehler im log.
+
Das debug kann später entfernt werden, zeigt aber jetzt möglich Fehler im log.<br><br>
  
Erster Test:
+
Erster Test:<br><br>
  
Nun öffnen wir mal die entsprechende Logdatei, um den Loginvorgang zu beobachten:
+
Nun öffnen wir mal die entsprechende Logdatei, um den Loginvorgang zu beobachten:<br><br>
  
tail -f /var/log/auth.log
+
tail -f /var/log/auth.log<br><br>
  
Nun versuchen wir uns von einem Telnetclient aus ein zu loggen, am einfachsten nehmt eine neue Console und gebt telnet localhost 4559 ein.
+
Nun versuchen wir uns von einem Telnetclient aus ein zu loggen, am einfachsten nehmt eine neue Console und gebt<br>telnet localhost 4559 ein.<br><br>
  
Folgender Willkommensstring sollte erscheinen:
+
Folgender Willkommensstring sollte erscheinen:<br><br>
  
  
~# telnet localhost 4559
+
~# telnet localhost 4559<br>
Trying 127.0.0.1...
+
Trying 127.0.0.1...<br>
Connected to localhost.localdomain.
+
Connected to localhost.localdomain.<br>
Escape character is '^]'.
+
Escape character is '^]'.<br>
220 localhost.localdomain server (HylaFAX (tm) Version 4.3.1) ready.
+
220 localhost.localdomain server (HylaFAX (tm) Version 4.3.1) ready.<br><br>
  
mit user testuser
+
mit user testuser<br>
und pass [password]
+
und pass [password]<br><br>
  
Kann man sich nun am Hylafaxserver anmelden.
+
Kann man sich nun am Hylafaxserver anmelden.<br><br>
  
'''Anmerkung:'''
+
'''Anmerkung:'''<br><br>
  
Wenn jetzt 530 Login incorrect erscheint, dann schauen wir jetzt mal in die Logdatei, hier sollte etwa folgendes stehen:
+
Wenn jetzt 530 Login incorrect erscheint, dann schauen wir jetzt mal in die Logdatei, hier sollte etwa folgendes stehen:<br><br>
  
localhost HylaFAX[4047]: (pam_unix) authentication failure; logname= uid=0 euid=10 tty= ruser= rhost=  user=testuser
+
localhost HylaFAX[4047]: (pam_unix) authentication failure; logname= uid=0 euid=10 tty= ruser= rhost=  user=testuser<br><br>
  
Ist dies der Fall, so besteht ein Problem mit den Rechten beim Zugriff von Hylafax auf die Datei /etc/shadow und /etc/passwd, welche für die Authentivizierung abgefragt werden müssen. Das Problem ist, dass Hylafax mit dem user uucp gestartet ist, dieser hat kein Recht die beiden Dateien zu lesen, somit schlägt die Anmeldung fehl.
+
Ist dies der Fall, so besteht ein Problem mit den Rechten beim Zugriff von Hylafax auf die Datei /etc/shadow und /etc/passwd, welche für die Authentivizierung abgefragt werden müssen. Das Problem ist, dass Hylafax mit dem user uucp gestartet ist, dieser hat kein Recht die beiden Dateien zu lesen, somit schlägt die Anmeldung fehl.<br><br>
  
Mit chmod o+r /etc/passwd und chmod o+r /etc/shadow kann man für einen Test mal die Rechte hochnehmen, '''UND BITTE NUR FÜR EINEN TEST !!!'''
+
Mit chmod o+r /etc/passwd und chmod o+r /etc/shadow kann man für einen Test mal die Rechte hochnehmen, '''UND BITTE NUR FÜR EINEN TEST !!!'''<br><br>
  
Nun sollte die Telnet Anmeldung reibungslos klappen.
+
Nun sollte die Telnet Anmeldung reibungslos klappen.<br><br>
  
~# telnet localhost 4559
+
~# telnet localhost 4559<br>
Trying 127.0.0.1...
+
Trying 127.0.0.1...<br>
Connected to localhost.localdomain.
+
Connected to localhost.localdomain.<br>
Escape character is '^]'.
+
Escape character is '^]'.<br>
220 localhost.localdomain server (HylaFAX (tm) Version 4.3.1) ready.
+
220 localhost.localdomain server (HylaFAX (tm) Version 4.3.1) ready.<br>
user testuser
+
user testuser<br>
331 Password required for testuser.
+
331 Password required for testuser.<br>
pass 123456
+
pass 123456<br>
230 User testuser logged in.
+
230 User testuser logged in.<br><br>
  
Ok, die PAM Authentivizierung funktioniert.
+
Ok, die PAM Authentivizierung funktioniert.<br><br><br>
  
  
'''JETZT: Dateirechte zurück ändern !!'''
+
'''JETZT: Dateirechte zurück ändern !!'''<br><br>
  
chmod o-r /etc/passwd
+
chmod o-r /etc/passwd<br>
chmod o-r /etc/shadow
+
chmod o-r /etc/shadow<br><br>
  
 
Teil eins ist geschafft, wer z.B. einen Sambaserver betreibt und die user lokal auf dem Server verwaltet, der ist mit dem jetzigen Stand vielleicht schon zufrieden.
 
Teil eins ist geschafft, wer z.B. einen Sambaserver betreibt und die user lokal auf dem Server verwaltet, der ist mit dem jetzigen Stand vielleicht schon zufrieden.
Im nächsten Schritt wollen wir die Authentivizierung so erweitern, dass endlich die vorhandenen user aus einem Windows Active Directory genutzt werden können.
+
Im nächsten Schritt wollen wir die Authentivizierung so erweitern, dass endlich die vorhandenen user aus einem Windows Active Directory genutzt werden können.<br><br><br>
  
  
 
----
 
----
  
'''Teil II'''
+
'''Teil II'''<br><br>
  
Zuerst benötigen wir das Paket openldap, wir werden davon nur den Client nutzen, ein zusätzliches PAM Modul, welches uns Zugriff zu ldap Servern verschafft, das da heißt libpam-ldap und die ldap Utilitys die uns später bei Tests helfen.  
+
Zuerst benötigen wir das Paket openldap, wir werden davon nur den Client nutzen, ein zusätzliches PAM Modul, welches uns Zugriff zu ldap Servern verschafft, das da heißt libpam-ldap und die ldap Utilitys die uns später bei Tests helfen. <br><br>
  
apt-get install slapd
+
apt-get install slapd<br>
apt-get install libpam-ldap
+
apt-get install libpam-ldap<br>
apt-get install ldap-utils
+
apt-get install ldap-utils<br><br>
  
Die grafische Konfigurationen klicken wir einfach durch, ohne irgend etwas anzugeben, dass machen wir gleich selber.
+
Die grafische Konfigurationen klicken wir einfach durch, ohne irgend etwas anzugeben, dass machen wir gleich selber.<br><br>
  
Nach der Installation der Pakete, ändern wir erneut die Date /etc/pam.d/hylafax, schließlich wollen wir ja jetzt nicht mehr das Hostsystem, sondern einen ldap Server abfragen.
+
Nach der Installation der Pakete, ändern wir erneut die Date /etc/pam.d/hylafax, schließlich wollen wir ja jetzt nicht mehr das Hostsystem, sondern einen ldap Server abfragen.<br><br>
  
Aus pam_unix.so wird nun pam_ldap.so
+
Aus pam_unix.so wird nun pam_ldap.so<br><br>
  
auth      sufficient    pam_ldap.so debug
+
auth      sufficient    pam_ldap.so debug<br>
account    sufficient    pam_ldap.so debug
+
account    sufficient    pam_ldap.so debug<br>
session    sufficient    pam_ldap.so debug
+
session    sufficient    pam_ldap.so debug<br><br>
  
Nun passen wir die ldap Parameter an.
+
Nun passen wir die ldap Parameter an.<br><br>
  
  
Die Datei /etc/ldap/ldap.conf wie folgt anpassen:
+
Die Datei /etc/ldap/ldap.conf wie folgt anpassen:<br><br>
  
HOST    192.168.1.250 (die IP des Active Directory Servers)
+
HOST    192.168.1.250 (die IP des Active Directory Servers)<br>
BASE    dc=testdomäne, dc=local (die Domäne des Active Directory Servers)
+
BASE    dc=testdomäne, dc=local (die Domäne des Active Directory Servers)<br><br>
  
Mehr braucht in der Datei nicht getan werden.
+
Mehr braucht in der Datei nicht getan werden.<br><br><br>
  
  
Nun editieren wir die Datei /etc/pam_ldap.conf
+
Nun editieren wir die Datei /etc/pam_ldap.conf<br><br>
  
Basissuchpfad ist
+
Basissuchpfad ist<br>
base dc=testserver,dc=local
+
base dc=testserver,dc=local<br><br>
  
ldap Server angeben (hier hat er die folgende IP)
+
ldap Server angeben (hier hat er die folgende IP)<br>
uri ldap://192.168.1.250
+
uri ldap://192.168.1.250<br><br>
  
wir benutzen die Protokollversion 3
+
wir benutzen die Protokollversion 3<br>
ldap_version 3
+
ldap_version 3<br><br>
  
anonyme Anfragen sind normalerweise nicht erlaubt am Active Directory, deswegen binden wir einen User mit entsprechenden Rechten an
+
anonyme Anfragen sind normalerweise nicht erlaubt am Active Directory, deswegen binden wir einen User mit entsprechenden Rechten an<br>
binddn Administrator@testserver.local
+
binddn Administrator@testserver.local<br><br>
  
dazu sein Passwort
+
dazu sein Passwort<br>
bindpw 123456
+
bindpw 123456<br><br>
  
Die Objektklasse nach der wir suchen ist User, also setzen wir den Filter dem entsprechend
+
Die Objektklasse nach der wir suchen ist User, also setzen wir den Filter dem entsprechend<br>
pam_filter objectclass=User
+
pam_filter objectclass=User<br><br>
  
den Loginnamen nehmen wir aus folgendem Attribut
+
den Loginnamen nehmen wir aus folgendem Attribut<br>
pam_login_attribute sAMAccountName
+
pam_login_attribute sAMAccountName<br><br>
  
zuletzt deaktivieren wir noch den SASL Sicherheitsmechanismus
+
zuletzt deaktivieren wir noch den SASL Sicherheitsmechanismus<br>
sasl_secprops maxssf=0
+
sasl_secprops maxssf=0<br><br>
  
  
Das war es soweit, nun sollte der Login für User die im angegebenen ldap Server existieren klappen, am besten wieder mit Telnet zu testen.
+
Das war es soweit, nun sollte der Login für User die im angegebenen ldap Server existieren klappen, am besten wieder mit Telnet zu testen.<br><br><br>
  
  
 
----
 
----
  
'''Teil III'''
+
'''Teil III'''<br><br>
  
Erweiterung der Konfiguration, damit nur User einer bestimmten Gruppe, z.B. Hylafax-User faxen dürfen.
+
Erweiterung der Konfiguration, damit nur User einer bestimmten Gruppe, z.B. Hylafax-User faxen dürfen.<br><br>
  
…folgt in Kürze / coming soon…
+
…folgt in Kürze / coming soon…<br><br><br>

Revision as of 09:55, 10 July 2007

Verlauf:
Erstellt am 10.07.2007

Ziel des Howto’s ist es, die Konfiguration des Hylafax Servers so zu ändern, um die Accounts aus einem Windows Active Directory zu holen. Standardmäßig werden die User Accounts in einer Datei namens hosts.hfaxd abgelegt, welche man mit dem Befehl faxadduser angelegt werden können. Im ersten Schritt werden wir Hylafax dazu bringen, die User Accounts des Linux Servers auf dem es läuft zu nutzen anstatt der hosts.hfaxd. Wenn dies funktioniert, kann es an die Hylafax-Ladp Konfiguration gehen. Ich gehe hier von einer Debian Installation aus. Wir brauchen den hylafax-server, openldap, von dem wir nur den Client nutzen und das Paket libpam-ldap.


Hylafax Version 4.2.0 oder höher sollte installiert und konfiguriert sein.


Teil I


- PAM Authentivizierung (Linux Maschinen Accounts) zum laufen bringen.

Zuerst sollte man prüfen ob PAM Support in der Hylafax Installation eingebunden ist, dies prüfen wir mit folgendem Befehl:

ldd /usr/sbin/hfaxd

wenn etwas wie

libpam.so.0 => /lib/libpam.so.0 (0xb7f02000)

aufgelistet wird, ist der PAM Support mit eingebunden, wenn nicht dann bitte eine aktuellere Version inkl. PAM Support installieren oder manuell den PAM Support einkompilieren.

Als nächstes legen wir einen Testuser im Linux System an, adduser testuser und bitte auch ein Passwort vergeben.

Nun die Datei /etc/pam.d/hylafax wie folgt editieren und falls notwendig erstellen:

auth sufficient pam_unix.so debug
account sufficient pam_unix.so debug
session sufficient pam_unix.so debug

Das debug kann später entfernt werden, zeigt aber jetzt möglich Fehler im log.

Erster Test:

Nun öffnen wir mal die entsprechende Logdatei, um den Loginvorgang zu beobachten:

tail -f /var/log/auth.log

Nun versuchen wir uns von einem Telnetclient aus ein zu loggen, am einfachsten nehmt eine neue Console und gebt
telnet localhost 4559 ein.

Folgender Willkommensstring sollte erscheinen:


~# telnet localhost 4559
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 localhost.localdomain server (HylaFAX (tm) Version 4.3.1) ready.

mit user testuser
und pass [password]

Kann man sich nun am Hylafaxserver anmelden.

Anmerkung:

Wenn jetzt 530 Login incorrect erscheint, dann schauen wir jetzt mal in die Logdatei, hier sollte etwa folgendes stehen:

localhost HylaFAX[4047]: (pam_unix) authentication failure; logname= uid=0 euid=10 tty= ruser= rhost= user=testuser

Ist dies der Fall, so besteht ein Problem mit den Rechten beim Zugriff von Hylafax auf die Datei /etc/shadow und /etc/passwd, welche für die Authentivizierung abgefragt werden müssen. Das Problem ist, dass Hylafax mit dem user uucp gestartet ist, dieser hat kein Recht die beiden Dateien zu lesen, somit schlägt die Anmeldung fehl.

Mit chmod o+r /etc/passwd und chmod o+r /etc/shadow kann man für einen Test mal die Rechte hochnehmen, UND BITTE NUR FÜR EINEN TEST !!!

Nun sollte die Telnet Anmeldung reibungslos klappen.

~# telnet localhost 4559
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 localhost.localdomain server (HylaFAX (tm) Version 4.3.1) ready.
user testuser
331 Password required for testuser.
pass 123456
230 User testuser logged in.

Ok, die PAM Authentivizierung funktioniert.



JETZT: Dateirechte zurück ändern !!

chmod o-r /etc/passwd
chmod o-r /etc/shadow

Teil eins ist geschafft, wer z.B. einen Sambaserver betreibt und die user lokal auf dem Server verwaltet, der ist mit dem jetzigen Stand vielleicht schon zufrieden. Im nächsten Schritt wollen wir die Authentivizierung so erweitern, dass endlich die vorhandenen user aus einem Windows Active Directory genutzt werden können.




Teil II

Zuerst benötigen wir das Paket openldap, wir werden davon nur den Client nutzen, ein zusätzliches PAM Modul, welches uns Zugriff zu ldap Servern verschafft, das da heißt libpam-ldap und die ldap Utilitys die uns später bei Tests helfen.

apt-get install slapd
apt-get install libpam-ldap
apt-get install ldap-utils

Die grafische Konfigurationen klicken wir einfach durch, ohne irgend etwas anzugeben, dass machen wir gleich selber.

Nach der Installation der Pakete, ändern wir erneut die Date /etc/pam.d/hylafax, schließlich wollen wir ja jetzt nicht mehr das Hostsystem, sondern einen ldap Server abfragen.

Aus pam_unix.so wird nun pam_ldap.so

auth sufficient pam_ldap.so debug
account sufficient pam_ldap.so debug
session sufficient pam_ldap.so debug

Nun passen wir die ldap Parameter an.


Die Datei /etc/ldap/ldap.conf wie folgt anpassen:

HOST 192.168.1.250 (die IP des Active Directory Servers)
BASE dc=testdomäne, dc=local (die Domäne des Active Directory Servers)

Mehr braucht in der Datei nicht getan werden.



Nun editieren wir die Datei /etc/pam_ldap.conf

Basissuchpfad ist
base dc=testserver,dc=local

ldap Server angeben (hier hat er die folgende IP)
uri ldap://192.168.1.250

wir benutzen die Protokollversion 3
ldap_version 3

anonyme Anfragen sind normalerweise nicht erlaubt am Active Directory, deswegen binden wir einen User mit entsprechenden Rechten an
binddn Administrator@testserver.local

dazu sein Passwort
bindpw 123456

Die Objektklasse nach der wir suchen ist User, also setzen wir den Filter dem entsprechend
pam_filter objectclass=User

den Loginnamen nehmen wir aus folgendem Attribut
pam_login_attribute sAMAccountName

zuletzt deaktivieren wir noch den SASL Sicherheitsmechanismus
sasl_secprops maxssf=0


Das war es soweit, nun sollte der Login für User die im angegebenen ldap Server existieren klappen, am besten wieder mit Telnet zu testen.




Teil III

Erweiterung der Konfiguration, damit nur User einer bestimmten Gruppe, z.B. Hylafax-User faxen dürfen.

…folgt in Kürze / coming soon…




Powered by MediaWiki
Attribution-ShareAlike 2.5

Project hosted by iFAX Solutions