FTP-Server mit Userauthentifizierung aus Active Directory

sparky23

Final Fantasy Freak
Hallo zusammen, habe da mal eine Verständnisfrage. Habe schon Google, das Wiki und die Foren durchsucht, aber mir ist das immer noch nicht so ganz klar geworden.

Also, ich habe auf der Arbeit einen FreeBSD-FTP-Server (vsftpd) zunächst zu Testzwecken eingerichtet. Der Server steht zur Zeit noch an meinem Arbeitsplatz. Die User habe ich erstmal lokal auf dem FTP-Server angelegt.

Dies ist aber ein wenig umständlich für die anderen Admins (keine Unix/Linux Kenntnisse vorhanden), wenn man sich jedesmal draufschalten muss (Server soll im Produktivbetrieb woanders stehen) um dort neue User anzulegen.

Frage:
Wie funktioniert es, dass sich die Benutzer mit ihren Active-Directory-Benutzernamen und ihrem Windows-Kennwort am FTP-Server anmelden können, damit man nicht alle User und Berechtigungen mehrmals anlegen bzw. vergeben muss?

Kann man das mit OpenLDAP oder so realisieren, oder braucht man zwangsläufig einen Samba-Server? Denn der FTP-Server soll wirklich nur FTP-Dienste anbieten als Standalone. Müsste ich dann zusätzlich einen Samba-Server aufsetzen? :confused:

Andere Frage:
Falls das nicht funktioniert und man tatsächlich alle FTP-Benutzer auf dem FTP-Server anlegen muss, gibt es dafür für Windows (XP) ein grafisches Frontend-Tool, mit dem man neue Benutzer auf dem Server anlegen und ihnen entsprechende Berechtigungen zuweisen kann?

MfG sparky23
 
hi

du musst dem vsftpd ldap beibringen
und dem AD server das er ldap spricht ( ist ein zusatz dienst )
das dann entsprechen configurieren und gut ist.

aber es geht alles mit ldap ......... nen zusaetzliches samba oder aenhnlich ist nicht noetig.

holger
 
Hi Holger, danke für deine schnelle Antwort!

Meinst du das hier?

"Windows Security and Directory Services for Unix"

Code:
[U]Overview[/U]
This guide provides prescriptive guidance on enabling Microsoft® Windows Server™ 2003 to be 
used for authentication and as an identity store within heterogeneous Microsoft Windows®
and UNIX environments. Windows uses the standards-based security and directory services 
provided by LDAP and Kerberos to provide secure and single sign-on capabilities between 
Windows, UNIX, and Linux systems.

The guidance covers evaluating, planning, building, deploying, and operating a security 
and directory infrastructure based on Windows Server 2003. It includes configuring both 
the Windows and UNIX/Linux settings and configuring the requisite Windows services. 
Technical guidance has been thoroughly lab tested with Windows Server 2003 SP1, Red Hat 
Linux 9, and Sun Microsystems Solaris 9.

Alternative solutions leading to five distinct end states are described within the 
following guide structure:

Volume 1: Overview and Envisioning. Provides an overview of authentication and
          authorization technologies and guides users through process of determining
          which of the five end states is most appropriate for their organization. 

Volume 2: Solutions Using Kerberos Authentication (End States 1 and 2).
          Describes implementation of End States 1 and 2 using different technology 
          approaches. In End State 1, UNIX clients use Active Directory Kerberos for 
          authentication but continue to use an existing UNIX-based data store for 
          authorization. In End State 2, UNIX clients use Active Directory Kerberos 
          for authentication and Active Directory LDAP for authorization.
 
Volume 3: Solutions Using LDAP Authentication. Describes implementation of End States 
          3 and 4 using different technology approaches. In End State 3, UNIX clients 
          use Active Directory LDAP for authentication and continue to use an existing 
          UNIX-based data store for authorization. In End State 4, UNIX clients use 
          Active Directory LDAP for both authentication and authorization. 

Volume 4: Describes implementation of End State 5, a cross-realm trust solution.
          UNIX and Windows infrastructures remain separate: UNIX clients use UNIX-based 
          Kerberos for authentication, Windows clients use Active Directory Kerberos
          for authentication, and a cross-realm trust enables UNIX and Windows users 
          (if the cross-realm trust is a two-way trust) to access services in the other side. 

Also included in the download package are several Word templates that can be used to create 
planning documents and other project deliverables and Excel tools that facilitate the 
identification and management of project risks and the selection of the most appropriate end state.

Note :
This release of the Windows Security and Directory Services for UNIX Guide includes volumes 1 and 2. 
Volumes 3 and 4 are planned for future releases.

Das klingt ja schonmal ganz gut, nur schade dass Endstate 3 und 4 noch nicht fertig sind.
Ich werde mir den ganzen Kram mal reinziehen. Hatte zwar schonmal gehört, dass es UNIX Services für Windows gibt,
aber mich damit nicht näher beschäftigt. Aber das ist ja echt interessant.
Cool von Microsoft, dass die so etwas anbieten.



Nochmal danke für deine Turbo-Antwort
 
sparky23 schrieb:
Meinst du das hier?
"Windows Security and Directory Services for Unix"
Ich sag jetzt mal nein. SFU ist etwas anderes.

mark05 schrieb:
und dem AD server das er ldap spricht ( ist ein zusatz dienst )
Das ActiveDirectory (sprich AD Server) spricht LDAP grundlegend (baut ja darauf auf).

du musst dem vsftpd ldap beibringen
@sparky23: Du musst deinem vsftpd beibringen, dass er User gegen LDAP verifiziert. Wie das geht müsste ja in der Doku zum vsftpd stehen. Als LDAP-Server gibst du dann den AD-Server an.
 
Ich weiß nicht ob der vsftpd pam unterstützt, gehe aber einfach mal davon aus ;-)

Du kannst mit samba (+winbindd), pam und nss das auch ganz hervorragend machen!

Habe das selber hier im Einsatz für IMAP, http und anderen Dienste am laufen.

Gerade wenn du noch andere Dienste übers AD authentifizieren willst, is die pam-Lösung auf lange Sicht einfacher zu pflegen, als die LDAP Unterstützung für jeden Dienst neu zu konfigurieren.
Habe auch mal nss_ldap und pam_ldap mit AD probiert - war aber gefühlt umständlicher ....

[gerad erst gesehen dass du samba nicht haben willst, sorry...]
 
hallo sparky23

funktionieren tuts eigentlich mit ldap auch schon. problem bei der sache ist, du must MSsfu3.x installiert haben. die ganzen dienste, die dabei mitinstalliert werden sind eigentlich unnütz (instabil), aber die attributserweiterungen im ad-schema sind für einen nachbau der passwd-zeile nötig.

1. reines ldap:
- anlegen eines proxyusers im ad (für die leseberechtigung des nss_ldap)
- befüllen der unix-attribute im ad
- kopieren des passwdhashes in das mssfu-passwd feld (säääääähr gefährlich)
- ldap.conf anpassen und die nsswitch.conf umstellen

2. ldpa als informationsdienst (was er ja auch eigentlich ist)
und kerberos zur authentifizierung.
- da is hier eine anleitung die für fedora funktioniert (habs selber ausprobiert)
sollte aber unter freebsd auch gehn

gruesse boeker

ps: bei fragen einfach nachfragen
 
Da sieht man mal, dass ich den vsftpd nicht selbst benutz... Jetzt muss ich mich doch erst mal selbst zitieren *g*
Wiedmann schrieb:
@sparky23: Du musst deinem vsftpd beibringen, dass er User gegen LDAP verifiziert. Wie das geht müsste ja in der Doku zum vsftpd stehen. Als LDAP-Server gibst du dann den AD-Server an.
Auf Grund der Antwort von boeker hab ich mir jetzt aber mal die Manpage angeschaut:
Tatsächlich kann der vsftpd nicht direkt LDAP. Man kann/muss dazu PAM benutzen, welches dann auf LDAP zugreift.

Selbst benutz ich den ProFTPd, der abgesehen über PAM, auch selbst ein Modul hat direkt mit einem LDAP-Server zu sprechen (wie der Apache z.B. auch). Da kann man dann den Microsoft AD benutzen wie er ist (s.u.).

boeker schrieb:
problem bei der sache ist, du must MSsfu3.x installiert haben.... aber die attributserweiterungen im ad-schema sind für einen nachbau der passwd-zeile nötig.
Tatsächlich fehlen dem AD im Zusammenspiel mit pam_ldap und nss_ldap ein paar Attribute. Man muss aber nicht unbedingt jetzt deswegen gleich SFU installieren, wenn man es nicht benötigt. Es langt, das vorhandene Schema um die fehlenden Attribute zu erweitern.
 
hallo,

die msSFU waren eingentlich nur vor servicerelease2 für win2003 server relevant,
um die unixattribute zu bekommen. ab sr2 sind sie standartmäsig eingepflegt.
(hatt noch vor sr2 mit basteln begonen :)

@wiedemann: sprichst du mit deinem proftp direkt mit ldap/ad, oder benutzt du das mssfu/passwd-feld?

ich konnte via ldap/ad nur mittels mssfu/passwd-feld authenifizieren.
jedoch der proxyuser war fähig via lsass.exe auf das original win passwort zuzugreifen.

boeker
 
boeker schrieb:
ch konnte via ldap/ad nur mittels mssfu/passwd-feld authenifizieren.
Das mod_ldap vom proFTPd benutzt standardmässig auch die Objectclass posixAccount im Suchfilter. Ab v2.7 von mod_ldap kann man da auch eigene angeben.
 
Danke für eure Tipps. Werde das spätestens nächste Woche mal ausprobieren.

Obwohl das ziemlich tricky ist.
:confused: Ich kann doch nicht einfach was auf dem DC installieren und ihn rebooten - *Angst*
Naja, muss ich mal mit Chef absprechen.

Sonst setz ich mir das ganze testweise mal zuhause auf. Ist wahrscheinlich besser...

1 DC mit W2k3
1 Client mit WinXP
1 FTP-Server vsftpd

-> süßes Mini-Netzwerk *g*

Ich sage aber noch bescheid, ob und wenn ja wie es geklappt hat...
 
Zurück
Oben