Hallo Christoph, wie Holger schon schrieb. LDAP-Anfrage durchführen und dann in die Log-Dateien sehen.
Die Logs findest Du in der Weboberfläche des IPFIRE unter Logs und dort unter Logdiagramme Ports. Unterhalb des Diagramms findest Du die Logs nach Ports aufgelistet und kannst sehen, ob die Anfrage unter dem Ldaps-Port geblockt wird. Wenn ja musst Du eine Firrewall-Regel erstellen die ldaps erlaubt. Gruß Alois 2015-02-22 9:13 GMT+01:00 Christoph Krebs <[email protected]>: > Also, einfach den ldaps-Port 636 probiert hatte ich schon ohne Erfolg... > Oder was genau sollte ich da machen? > Ich bring mal die Logdateien, wie Holger es sagt, hier gleich schon mal > eine slapd.conf. > Mit "Anfrage generieren" meinst Du, ich soll einfach auf einem Client > einen Browser starten, oder?!? > > Danke und Gruß > Christoph > > slapd.conf: > > ##### ##### Do not change this file! It will be overwritten! > ##### ##### This configuration file was automatically created by > linuxmuster-setup! > ##### ##### Last Modification: Fr 1. Aug 23:56:22 CEST 2014 > # $Id: slapd.conf 1334 2012-07-20 12:03:39Z tschmitt $ > ####################################################################### > # > # Global Directives: > > # Features to permit > #allow bind_v2 > > # Schema and objectClass definitions > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/misc.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > include /etc/ldap/schema/samba.schema > include /etc/ldap/schema/sophomorix.schema > > # Schema check allows for forcing entries to > # match schemas for their objectClasses's > #schemacheck on > > # Where the pid file is put. The init.d script > # will not stop the server if you change this. > pidfile /var/run/slapd/slapd.pid > > # List of arguments that were passed to the server > argsfile /var/run/slapd/slapd.args > > # Read slapd.conf(5) for possible values > loglevel 0 > > # Where the dynamically loaded modules are stored > modulepath /usr/lib/ldap > moduleload back_hdb > > # The maximum number of entries that is returned for a search operation > sizelimit unlimited > > # use passwords encrypted with ssha > password-hash {SSHA} > > ####################################################################### > # Specific Backend Directives for bdb: > # Backend specific directives apply to this backend until another > # 'backend' directive occurs > backend hdb > > ####################################################################### > # Specific Directives for database #1, of type sql: > # Database specific directives apply to this databasse until another > # 'database' directive occurs > database hdb > > #LDAP Suffix > suffix "dc=msg,dc=lokal" > > #LDAP Admin > rootdn "cn=admin,dc=msg,dc=lokal" > rootpw tbkvgemk > > # Where the database file are physically stored for database #1 > directory "/var/lib/ldap" > > # The dbconfig settings are used to generate a DB_CONFIG file the first > # time slapd starts. They do NOT override existing an existing DB_CONFIG > # file. You should therefore change these settings in DB_CONFIG directly > # or remove DB_CONFIG and restart slapd for changes to take effect. > > # For the Debian package we use 2MB as default but be sure to update this > # value if you have plenty of RAM > dbconfig set_cachesize 0 2097152 0 > > # Sven Hartge reported that he had to set this value incredibly high > # to get slapd running at all. See http://bugs.debian.org/303057 for more > # information. > > # Number of objects that can be locked at the same time. > dbconfig set_lk_max_objects 1500 > # Number of locks (both requested and granted) > dbconfig set_lk_max_locks 1500 > # Number of lockers > dbconfig set_lk_max_lockers 1500 > > # Indexing options for database #1 > index objectClass,uid,uidNumber,gidNumber,memberUid eq > index cn,mail,surname,givenname eq,subinitial > index sambaSID eq > index sambaPrimaryGroupSID eq > index sambaDomainName eq > > # Save the time that the entry gets modified, for database #1 > lastmod on > > # Checkpoint the BerkeleyDB database periodically in case of system > # failure and to speed slapd shutdown. > checkpoint 512 30 > > ####################################################################### > #Limits Access: > access to attrs=sambaLMPassword,sambaNTPassword,sambaPwdLastSet, > sambaPwdMustChange,sambaAcctFlags,userPassword > by anonymous peername.ip=10.16.1.254 auth > by anonymous peername.ip=10.16.1.1 auth > by anonymous peername.ip=127.0.0.1 auth > by anonymous ssf=56 auth > by self peername.ip=127.0.0.1 write > by self ssf=56 write > by * none > > access to * > by * read > > ####################################################################### > # TLS: > #TLSCipherSuite HIGH:MEDIUM:+SSLv2 > TLSCACertificateFile /etc/ssl/private/server.pem > TLSCertificateFile /etc/ssl/private/server.pem > TLSCertificateKeyFile /etc/ssl/private/server.pem > > # Use the following if client authentication is required > #TLSVerifyClient demand > # ... or not desired at all > #TLSVerifyClient never > > #The cachesize directive defines the number of entries that the LDAP > backend will maintain in memory > #cachesize 10000 > > > > Am 22.02.2015 02:58, schrieb Alois Raunheimer: > >> Hallo Christoph, >> >> ok, Holger bekommt 50 von 100 Euro und ich den Rest ;-). >> >> Gruß >> >> Alois >> >> Ps. Meinen Anteil kannst Du dem Verein linuxmuster.net >> <http://linuxmuster.net> spenden >> >> Am 22. Februar 2015 um 02:38 schrieb Holger Baumhof >> <[email protected] <mailto:[email protected]>>: >> >> >> Hallo Christoph, >> >> > 3. Warum zum Geier habt Ihr IPFire bei 6.1 umgestellt auf >> > IP-Adresen-basierte Zugriffskontrolle? Man ändert doch nicht >> einfach so >> > etwas, was gut funktioniert!!! >> >> weil die lml 6.1 auch auf subnetting umgestellt werden kann: und MAC >> Adressen kommen nicht durch den Layer 3 Switch: also muß alles auf IP >> Ebene gehen und nicht mehr auf MAC Ebene. >> Das ganze sollte dein Problem aber garnicht berühren. >> >> Ich schätze das Problem ist woanders. >> >> Die Firewall des Servers oder der slapd nehmen keine ldap Anfragen 389 >> mehr an: du stellst also ldaps ein, aber der IPFire lehnt das selbst >> signierte Zertifikat des Server ab: Abhilfe: IPFire modifizieren, dass >> er mit dem selbstsignierten Zertifikat zurecht kommt, oder slapd >> beibringen, dass er vom IPFire auch unverschlüsselte Anfragen annimmt >> (und der Serverfirewall das auch erklären). >> >> Wo es klemmt bekommt man aber normalerweise ganz gut mit Geduld und >> Spucke heraus, indem man eine Anfrage generiert (die nicht klappt) und >> während dessen die zutreffenden Logfiles überwacht. >> Oder man durchsucht sie danach. >> >> Bitte poste mal die Dateien: >> /etc/linuxmuster/allowed_ports und /etc/ldap/slapd.conf >> des Servers. >> In der slapd das ldapsecret unkenntlich machen. >> >> Viele Grüße >> >> Holger >> -- >> Mein öffentlicher PGP-key ist hier hinterlegt: >> pool.sks-keyservers.net <http://pool.sks-keyservers.net> >> _______________________________________________ >> linuxmuster-user mailing list >> [email protected] >> <mailto:[email protected]> >> https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user >> >> >> >> >> _______________________________________________ >> linuxmuster-user mailing list >> [email protected] >> https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user >> >> _______________________________________________ > linuxmuster-user mailing list > [email protected] > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user >
_______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
