WYSIWYG gefixed

Hmmm, das ist schon da. Vielleicht doch nicht zuerst Base adden sollen ? Gibts da kein --force-all ? :-D

Ok, weiter gehts :-D

Wie man oben sieht, gibts nen ou=people, keine Ahnung wo das herkommt. 

Aber der Output von den migrationtools gibt an ou=People. Und Samba will ou=Users. Öhm, viel Auswahl wenn man keine Ahnung hat. 

Ich entscheide mich jetzt mal für den Debian default und nehme People. Mal sehen ob ichs bereue :-D

Also rm people weggelöscht und diesmal das  /tmp/nis.ldif.XXXXXX eingespielt.

Sieht schon besser aus.

Also nen bischen was hat er mal importiert. 

Peoples mal gar keine. 

Also testweise mal einen user als ldif erstellen und adden. 

Das File sieht in etwa so aus:

dn: uid=daniel,ou=People,dc=chii,dc=homedns,dc=org
uid: daniel
cn: daniel
sn: daniel
mail: daniel@chii.homedns.org
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: krb5Principal
objectClass: shadowAccount
userPassword: {crypt}sicheristsicherauchwenndenhashzuwisseneigentlichnichtsbringensollte

shadowLastChange: 14643
shadowMax: 99999
shadowWarning: 7
krb5PrincipalName: daniel@CHII.HOMEDNS.ORG
loginShell: /bin/bash
uidNumber: 1003
gidNumber: 1004
homeDirectory: /home/daniel
gecos: ,,,

Aha, adden failed.

Grund:  
objectClass: krb5Principal <- kennt er nicht. 

Denke mal das Schema fehlt, aber ich hab den Ticketwauwau (Kerberos) auch noch gar nicht eingerichtet. 

Naja, bevor ich per Suchen/Ersetzen das Zeug bei allen Usern lösche, schau ich mal ob ich das Schema einbinden kann. Später soll ja krb laufen (Win AD).

apt-get install krb5-kdc-ldap

und

nutte:/home/dominik# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config

dn: cn=module{0},cn=config

dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}inetorgperson,cn=schema,cn=config

dn: cn={3}openldap,cn=schema,cn=config

dn: cn={2}nis,cn=schema,cn=config

dn: cn={5}misc,cn=schema,cn=config

dn: cn={6}samba3,cn=schema,cn=config

dn: cn={7}gosystem,cn=schema,cn=config

dn: cn={8}gofon,cn=schema,cn=config

dn: cn={9}gofax,cn=schema,cn=config

dn: cn={10}goto,cn=schema,cn=config

dn: cn={11}goserver,cn=schema,cn=config

dn: cn={12}gosa-samba3,cn=schema,cn=config

dn: cn={13}trust,cn=schema,cn=config

dn: olcBackend={0}hdb,cn=config

dn: olcDatabase={-1}frontend,cn=config

dn: olcDatabase={0}config,cn=config

dn: olcDatabase={1}hdb,cn=config

 

Hmmm also krb ist noch nicht drin aber das viele goXX Zeug erklärt vielleicht wo das people klein herkommt. Sieht nach Gosa aus. Ist auch installiert, aber auch nicht eingerichtet bisher :-D Ich befürchte ich muss irgendwann mal "apt-get install alleswasmitldapzutunhat" eingetippert habe. 

Egal erstmal. 

sudo gzip -d /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz
sudo cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema /etc/ldap/schema/

dann schema_convert.conf erstellen mit Inhalt:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/kerberos.schema

dann 

slaptest -f schema_convert.conf -F /tmp/ldif_output -n0 -s "cn={12}kerberos,cn=schema,cn=config" > /tmp/cn=kerberos.ldif

(slaptest -f schema_convert.conf -F /tmp/ldif_output)

kerberos.ldif editieren:

Kop abändern auf:

dn: cn=kerberos,cn=schema,cn=config
...
cn: kerberos

und Block am Ende ab:

structuralObjectClass: olcSchemaConfig

weglöschen und mit 

ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/cn\=kerberos.ldif reinschiessen.

Total einfach oder ? LOL

Hmmm nebenbei fällt mir auf das ich mit dem weglöschen von people klein auch gleich den admin mitgelöscht habe. Sehr schlau von mir :-D

Immerhin war ich so schlau das people als ldif vorher zu exportieren. Also den Prt für den Admin rausnehmen, people auf People abändern und wieder reinschiessen.

dn: cn=System Administrator-admin,ou=People,dc=chii,dc=homedns,dc=org
cn: System Administrator-admin
givenname: System
objectclass: top
objectclass: person
objectclass: gosaAccount
objectclass: organizationalPerson
objectclass: inetOrgPerson
sn: Administrator
uid: admin
userpassword: {CRYPT}Sagichnicht

Keine Ahnung welcher Admin das ist. Ob nur für Gosa oder ldap admin, für dc=chii oder dc=admin,dc=config oder oder.. Ich hab in der config von slapd nochmal ein Adminaccount. Egal, sicher ist sicher und kostet erstmal nix. Ich befürchte das ich das auch noch an anderer Stelle auf People umstellen muss. Zumindest mal in Gosa aber erstmal will ich ein populated ldap tree. 

gosa, pam, nscd, kerberos, samba, und und und kommt später...

Also die ldapmodify ist übrigens ein Superbeispiel warum ich mit 10 Usern ein ldap haben will :-D

Ich hab die Schnautz so voll von 20 Millionen Authmethoden, ich will EINE. 

ldapmodify will ohne Parameter erstmal über sasl authentifizieren, sasl nutzt bei mir saslauthd, das wiederrum pam benutzt das via pam-ldap auf ldap zugreift.

Gehts komplizierter ? Ich glaube nicht. :-D

Vor allem SASL finde ich persönlich den größten Dreck. Wenn schon kein flat (passwd like) dann gleich ldap. Aber cyrus ist kompliziert und Mist meiner Meinung nach:-D

Ok, in cn=config noch den index für kerberos aufgenommen.  [inline:krbACL.ldif] [inline:krbindex.ldif]

Mal sehen ob der Testuser daniel von oben jetzt reingeht.

ldap_add: Invalid syntax (21)
additional info: objectClass: value #5 invalid per syntax

War ja klar, nö.

Schnauze voll erstmal. To be continued irgendwann....

Öhm wer ins File guckt, ist klar im Vorteil. In kerberus.schema gibts  
krb5Principal auch nicht. 

Da aber schon: /usr/share/doc/gosa-plugin-mit-krb5/contrib/hdb.schema

Also das ganze von oben nochmal und zusätzlich hdb.schema als ldif ab in den slapd. 

Und siehe da es funzt. Was heimdal und kerberus vom MIT mit unterscheidet, lese ich mal nach wenn ich mich mit kerberus beschäftige (20 Jahren wenn es weiter so geht)

 

Ok, Feiertag, guter Anlass weiter an ldap rumzuspielen. 

Kurzer Zwischenstand. 

ldapsearch -x -W -D 'cn=admin,dc=chii,dc=homedns,dc=org' '*'

geht und zeigt mir den kompletten ldap tree. OK

ldapsearch -x -D 'uid=dominik,ou=People,dc=chii,dc=homedns,dc=org' -W

Zumindest die AUTH klappt mit dem Passwort für dominik das im ldap steht aber Result 0. 

Hmmm keine Ahnung ob das ok :-D

Logging für slapd

olcLogLevel auf 256 in /etc/ldap/slapd.d/cn=config.ldif gesetzt und slapd restarted. 

rsyslog geadded: Anscheined printed sonst slapd das auf LOCAL4

local4.* /var/log/ldap.log

rsyslog restart. 

Soooo, logging klappt. 

Noch spezifischer:

ldapsearch -h localhost -p 389 -x -D "uid=dominik,ou=People,dc=chii,dc=homedns,dc=org" -b "uid=dominik,ou=People,dc=chii,dc=homedns,dc=org" -W

AUTH klappt und result ist weiter 0.

Sollte ich nicht mindestens meinen eigenen Eintrag lesen können ? Ich glaube da stimmt was nicht an den ACLs.

ldapmodify will als cn=admin,dc=config mein Passwort nicht.

/etc/ldap/cn=config/olcDatabase={0}config.ldif RootPW fehlt.

Hinzugefügt. 

ACLs anschauen:

ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase=hdb olcAccess
Enter LDAP Password:
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn
=admin,dc=chii,dc=homedns,dc=org " write by anonymous auth by self write by *
none

Ok, in deutsch: Admin darf userPassword schreiben, anonymous darf authen und der user selbst darf passwort schreiben. 

Sonst gibts keine Regeln. 

Bischen radikal find ich. Sowas wie nonanonymous dürfen zumindest ou=People uid, mail und anders nicht sicherheitskritisches lesen.