dr.disk

Ob das Postfix von sich aus kann würde ich jetzt mal eher bezweifeln. Was aber geht ist wenn man ein eigenes Modul schreibt und dieses in Postfix integriert.

Weiß nicht genau welche Version ich habe. Sollte ziemlich aktuell sein - ist sicherlich aber nicht die 'Neuste'. Mal damit bei Gelegenheit mein Glück probieren. Was ich mir auch schon mal überlegt habe ist das Backend auszutauschen. Bringt ja vielleicht auch noch was... Für die Authentifizierung sollte das hier reichen: # Passwort schuetzen access to attrs=userPassword by self write by * auth # Rest darf lesen access to * by * read Lesen darf sowieso jeder und das muss ja auch so sein, sonst könnte auch das System selbst nicht zugreifen. Nur das Passwort sollte geschützt werden - das macht die erste Regel: das Feld userPassword darf nur von dem jeweiligen User geschrieben werden, alle anderen dürfen es nur für die Authentifizierung nutzen.

Das ist schon klar. Sobald die bei mir aber drin sind geht leider nur noch die Hälfte. Muss mal ein Update von OpenLDAP suchen und mal schauen, was dann passiert.

Bei slapcat taucht der User auf, beim getent nicht? Ist das richtig so? Steht der User auch an der richtigen Stelle im LDAP? Ich hatte auch so ein Problem. Nachdem ich fast alle 'index' Einträge entfernt habe hat's dann auch geklappt. Was bei mir ebenfalls noch einige Besserungen gebracht hat war der Austausch von rfc2307bis.schema durch nis.schema. Und hier meine Config: # # rofa.rocl.local OpenLDAP Konfigruation # # Schema includieren include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema #include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/amavisd-new.schema #include /etc/openldap/schema/yast.schema #include /etc/openldap/schema/moz.schema include /etc/openldap/schema/mozillaOrgPerson.schema # Allgemeine Einstellungen pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args #loglevel 392 # Backend-Module einbinden modulepath /usr/lib/openldap/modules # moduleload back_ldap.la # moduleload back_meta.la # moduleload back_monitor.la # moduleload back_perl.la # SASL #sasl-host rofa.rock.local #sasl-realm ldap://RoFa.Rock.Local #sasl-secprops noplain,minssf=0 # TLS TLSCertificateFile /etc/openldap/ldap.crt TLSCertificateKeyFile /etc/openldap/ldap.key TLSCACertificateFile /etc/openldap/cacert.pem TLSCipherSuite HIGH:MEDIUM #TLSVerifyClient allow # weitere Sicherheitseinstellungen password-hash {SSHA} ################################################################################ ##### Auth-Database (NSS + PAM) ##### database bdb cachesize 500 checkpoint 1024 5 suffix "dc=Rock,dc=Local" rootdn "cn=Manager,dc=Rock,dc=Local" rootpw {SSHA}AL+uBzZm369rR4iSW1rzSXAKCdN3JwDW directory /var/lib/ldap/Rock_Local index objectClass eq #index uid pres,eq #index uidNumber eq #index gidNumber eq #index cn pres,eq,sub # Passwort schuetzen access to attrs=userPassword by self write by * auth # Rest darf lesen access to * by * read

Das hat nichts mit der LDAP oder PAM Konfiguration zu tun wo useradd seine User ablegt. Bei mir geht's über den Schaler '--service ldap'. Sobald der gesetzt ist wird der User im LDAP und nicht in den Dateien eingetragen.

Lass bei der --to-destination einfach die Ports weg, dass sollte funktionieren.

Dazu fallen mir auf die Schnelle folgende Lösungsansätze ein: Jenachdem wieviele Rechner Ihr habt kann man auch mit bestimmten Bereichen arbeiten. Z.B. die Adressen 1-31 haben vollen Zugriff aufs Internet, 32-63 beschränkten usw. Die mit vollem Zugriff haben statische IPs, die 'beschränkten' haben dynamische. Jeder der aus einem der bestimmten Bereiche kommt landet automatisch in der jeweiligen Kategorie. Solange es nicht viele Rechner sind hält sich der Aufwand hierbei in Grenzen. DHCP mit DNS. Der DHCP-Server kann im DNS Einträge setzen, d.h. zu der vergebenen IP kann er einen Rechnernamen setzen und diesen könnte man in Squid abprüfen. Gefällt mir persönlich aber nicht so gut diese Lösung. DNS mit DHCP. Windows Rechner können Ihren Namen im DNS eintragen sobald diese eine IP erhalten haben. Der Rest ist analog zu dem eins drüber - von der Tatsache mal abgesehen, dass dies halt nur mit Windows Rechnern funktioniert (bei Win ist' halt schon drin <-- bevor hier irgendjemand meckert...). Authentifikation. Bevor ein Benutzer ins Internet kann, wird er nach Benutzernamen und Paßwort gefragt. Anhand des Benutzernamens ist es dann möglich die Beschränkungen zu definieren. Ein schöner Vorteil davon ist, dass man auch mal an einem anderen Rechner un-/beschränkten Zugriff auf das Internet haben kann. Das ist die Lösung die ich meistens bevorzuge. Ein Quota System bietet die Kombination aus Volumen- und Seitenbeschränkungen. Das könnte ja ebenfalls was sein. Ich kenne da derzeit eigentlich nur squidquota aus der SquiVi2 Sammlung (squivi2.sf.net).

Hab's jetzt bei Softpedia gefunden: eine Trial Version von PCMaclan. Das reicht mir völlig aus, der Server unter Linux funktioniert. Danke an alle die hier mir geholfen haben!

netatalk unter Linux. Ich würde gerne testen, ob der Fileserver läuft, habe aber keinen Mac zur Hand.

Da sehe ich aber leider nichts. Was muss ich tun?

Hallo, ich suche einen Client mit dem ich vom Windows aus auf einen Apple Fileserver zugreifen kann. Danke!

Hallo, ich suche eine Möglichkeit wie man Spybot von Remote auf Arbeitsplätzen installiert - analog zu Dameware oder Remotely VNC. Kennt jemand von Euch da eine Möglichkeit? Danke, Steffen.

Hhm - ein Speichertest lief da eigentlich vor einem Monat mal eine ganze Nacht lang durch... Naja, werde es trotzdem bei Gelegenheit nochmals testen.

'otto' heißt die Maschine. Die Meldung ist auch nicht von dem betroffenen System, sondern irgendwo aus dem Internet heraus kopiert. Ich hab die Meldung am Telefon erhalten und halt selbst schon mal gesucht - bisher gab's noch keine weiteren Erkenntnisse; bin noch mittendrin :hells:

Morgen zusammen! Was will mir der Linux-Kernel mit folgender Meldung sagen: Mar 14 09:00:01 otto kernel: Uhhuh. NMI received for unknown reason 3d. Mar 14 09:00:01 otto kernel: Dazed and confused, but trying to continue Mar 14 09:00:01 otto kernel: Do you have a strange power saving mode enabled? Ach ja, ist ein SuSE 9.3 - die Meldung kann man aber laut Google sogar schon bei Kernels 2.4.x erhalten. Beim Board handelt es sich um ein Intel-Serverboard (hab die Version gerade nicht da) mit einem Intel Celeron 2,8.

Diese Zeile gehört an die richtige Stelle in der jeweiligen PAM-Datei. Falls die User per ssh kommen ist's die sshd, falls per lokalem Login die Datei login. Weitere Infos findest Du auch in der Doku unter /usr/share/doc/packages/pam. Die LDAP Struktur ist doch ok so - falls Sie Eure Situation gut genug abbildet.

Mein Blowfish Feld ist leer - habe bisher noch nie Bedarf gehabt da was reinzuschreiben... Unten in der ldap.conf findest Du doch Einträge wie z.B. den folgenden: 'nss_base_passwd'. Da musst Du halt die entsprechende Basis reinschreiben für den Inhalt von passwd (und analog für die Gruppen usw.). Ein kleines Beispiel: nss_base_passwd ou=People,ou=Einkauf,ou=Stuttgart,dc=Rock,dc=Local

Entweder so oder einfach ganz weglassen - da geht beides.

Ach ja, die phpldapversion die ich benutze ist die 0.9.6 - eigentlich die Gleiche wie bei Dir...

Unterteilen kannst Du das ganze indem Du in LDAP ou bildest. Auf den jeweiligen Clients muss man dann halt in der LDAP Konfiguration die jeweilige ou angeben und nicht den Wurzelknoten. Wer's ganz sicher haben will muss dann halt noch am Berechtigungsmodel drehen, idR. reicht aber die 1. Variante bereits völlig aus.

Um das Servergespeicherte Profil zu deaktiveren sind die entsprechenden Felder in der Sambakonfiguration einfach leer zu lassen. Das war's auch schon. Anmeldeskripte funktionieren natürlich ebenfalls. Diese müssen in der Freigabe netlogon liegen (evtl. halt noch anlegen) und dem User auch unter Windows zuweisen. Das Argument heißt glaube ich 'Logon Script' - den genauen Namen müsste ich nachsehen falls es weiterhin Probleme gibt.

Hallo, ich habe hier einfach mal den Teil meiner Config angehängt mit dem es bei mir funktioniert. Der UID-Pool ist zunächst noch uninteressant, da kann also stehen was will. $servers[$i]['name'] = 'Rock.Local'; $servers[$i]['host'] = 'localhost'; $servers[$i]['base'] = 'dc=Rock,dc=Local'; $servers[$i]['port'] = 389; $servers[$i]['auth_type'] = 'config'; $servers[$i]['login_dn'] = 'cn=Manager,dc=Rock,dc=Local'; $servers[$i]['login_pass'] = 'blablabla'; $servers[$i]['tls'] = false; $servers[$i]['low_bandwidth'] = false; $servers[$i]['default_hash'] = 'crypt'; $servers[$i]['login_attr'] = 'dn'; $servers[$i]['login_string'] = 'uid=<username>,ou=People,dc=example,dc=com'; $servers[$i]['login_class'] = ''; $servers[$i]['read_only'] = false; $servers[$i]['show_create'] = true; $servers[$i]['enable_auto_uid_numbers'] = true; $servers[$i]['auto_uid_number_mechanism'] = 'search'; $servers[$i]['auto_uid_number_search_base'] = 'ou=People,ou=Auth,dc=Rock,dc=Local'; $servers[$i]['auto_uid_number_min'] = 10000; $servers[$i]['auto_uid_number_uid_pool_dn'] = 'cn=uidPool,dc=example,dc=com'; $servers[$i]['auto_uid_number_search_dn'] = ''; $servers[$i]['auto_uid_number_search_dn_pass'] = ''; $servers[$i]['disable_anon_bind'] = false; $servers[$i]['custom_pages_prefix'] = 'custom_'; $servers[$i]['unique_attrs_dn'] = ''; $servers[$i]['unique_attrs_dn_pass'] = '';

Ja, zentral ist das sicherlich besser. Ein Stichwort ist da automout. Ich hab's bei mir noch nicht mit LDAP laufen - da fehlte mir bisher die Zeit - sondern nur in einigen NIS-Domains. Funktioniert aber auch mit LDAP.

Unter SuSE Linux sind keine Änderungen an den pam-Dateien notwendig - dass macht Yast alles für einen. Welches SuSE Linux ist eigentlich im Einsatz? Auf dem Client muss der User mittels getent ... angezeigt werden, sonst klappt's nicht. Habe im ersten Thread mal nach ganz rechts gescrollt: da steht drin TLS aktiviert. Läuft das auch auf dem Server? Schalte TLS einfach mal ab und probier's dann nochmals. Falls das dann immer noch nicht funktioniert hätte ich gerne mal einen Blick in folgende Dateien geworfen: Server: /etc/openldap/slapd.conf Client: /etc/nsswitch.conf /etc/security/pam_unix2.conf /etc/ldap.conf

Melde Dich am Client an und füre folgenden Befehl aus: getent passwd Taucht in dieser Liste Dein LDAP-User auf? Falls ja scheint LDAP richtig integriert zu sein. Ich selbst nutze normalerweise nicht Yast um LDAP-User anzulegen sondern phpldapadmin (phpldapadmin.sf.net). Was mir aber gerade noch auffällt ist, dass die Klasse 'shadowAccount' nicht genutzt wird. Ein getent shadow sollte Deinen LDAP-User nicht finden und deswegen klappt auch die Anmeldung nicht. Ich hänge hier mal ein Beispiel an wie z.B. mein LDAP-Account aussieht. Lass Dich aber nicht davon stören, dass da noch mein Samba-Account und auch meine Postfix-/Amavis-Einstellungen drin stehen: # Eintrag 1: uid=steffen,ou=People,ou=Auth,dc=Rock,dc=Local dn: uid=steffen,ou=People,ou=Auth,dc=Rock,dc=Local objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: sambaSamAccount objectClass: amavisAccount cn: steffen sn: steffen uid: steffen uidNumber: 1002 gidNumber: 513 homeDirectory: /home/steffen loginShell: /bin/bash gecos: System User sambaSID: S-1-5-21-137636792-4063881662-3838030484-3004 sambaPrimaryGroupSID: S-1-5-21-137636792-4063881662-3838030484-513 displayName: Steffen Schoch sambaKickoffTime: 0 sambaPasswordHistory: 000000000000000000000000000000000000000000000000000000 0000000000 sambaLogonHours: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF sambaAcctFlags: [U ] sambaPwdCanChange: 1115460024 sambaPwdMustChange: 2147483647 sambaLMPassword: 9C722E2517CAE830AAD3B435B51404EE sambaNTPassword: 11E8485C17199DAAEA9F57BB466C3EB9 sambaPwdLastSet: 1115460024 userPassword: {SSHA}X+qlxteo2U9S7A8rzz9BM4lcnTeu1HPX amavisSpamModifiesSubj: TRUE mail: XXXXXX@XXX.XXX mail: XXXXXX@XXX.XX mail: XX.XXXX@XXX.XX mail: XX.XXXX@XXX.XXX mail: steffen@rock.local Nicht nötig ist sambaSamAccount und amavisAccount für eine Linux Authentifizierung.