Sooo, ich hab' heute nochmal neu die ldap.conf auf den USB-Stick gezogen, und siehe da: Sie ist fast leer!

Möglich, dass ich die gestern gepostete Version noch vor dem Durchlauf des linuxmuster-ipfire-Skripts kopiert hatte... Jetzt scheint da jedenfalls irgendwas völlig im Eimer zu sein, sehr merkwürdig.

Kann ich einfach die alte Datei für den neuen IPFire übernehmen, oder wurde bei der seit Babo bzw. der Filterung über IP-Adressen etwas geändert?!?

Und wie kann man eigentlich feststellen, ob IPFire in der zu lml 6.1 passenden Version läuft bzw. ob die FIlterung über IP-Adressen aktiviert ist? Nicht, dass das Skript nur ein, zwei Dateien verhauen hat und IPFire sonst noch der alte ist...

Danke und Gruß
Christoph







Am 22.02.2015 09:49, schrieb Alois Raunheimer:
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]
<mailto:[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>
        <http://linuxmuster.net> spenden

        Am 22. Februar 2015 um 02:38 schrieb Holger Baumhof
        <[email protected] <mailto:[email protected]>
        <mailto:[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>
        <http://pool.sks-keyservers.__net <http://pool.sks-keyservers.net>>
             _________________________________________________
             linuxmuster-user mailing list
        linuxmuster-user@lists.__linuxmuster.net
        <mailto:[email protected]>
             <mailto:linuxmuster-user@__lists.linuxmuster.net
        <mailto:[email protected]>>
        https://mail.lehrerpost.de/__mailman/listinfo/linuxmuster-__user
        <https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user>




        _________________________________________________
        linuxmuster-user mailing list
        linuxmuster-user@lists.__linuxmuster.net
        <mailto:[email protected]>
        https://mail.lehrerpost.de/__mailman/listinfo/linuxmuster-__user
        <https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user>

    _________________________________________________
    linuxmuster-user mailing list
    linuxmuster-user@lists.__linuxmuster.net
    <mailto:[email protected]>
    https://mail.lehrerpost.de/__mailman/listinfo/linuxmuster-__user
    <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

Antwort per Email an