LDAP kinlodas

Termeszetesen megvalosithato. Amit fentebb irtam, nagyon jo kis leiras.
Ha azon vegighaladsz, a getent passwd vagy getent gorup (hmm, man getent :) kiirja, hogy kiket talal. Tehat a leiras szerint bellitva (aaszem, az /etc/nsswitch kornyeken, fehjbol nem tudom) lehet beallitani, hogy eloszor a passwd/group file-t nezze, utana keressen az ldap-on.

Ujabb osszefoglalo :)
Hetvegen otthon is megprobaltam. Ugyanott halt meg, mint melohelyen, vagyis konzolon nem enged be. Viszotn amit eszrevettem: en poen kedveert telepites utan az /etc/ldap/slapd.conf-ben atirtam a dir-t /var/lib/ldap/celtic-re. Es rogton nem letezett a rootdn, letrehozni sem tudtam, semmi. Ha az eggyel feljebb (tehat /var/lib/ldap) cuccokat _atmasoltam_ (ugyanazt a fileszerkezetet letehozni nem erdemes, inkabb masolni), akkor mukodott. Es asszem itt volt a megoldas: maga az ldap telepiteskor az elso cimtarban letrehozza a rootdn-t (en aszittem, ezt csak az /etc/ldap/slapd.conf-ban tarolja, mintha a leirasok ezt mondtak volna). Hat most kideult, hogy magaban az adatbazisban is :(

namost, melohelyen cucc lepucol (slapd, phpldapadmin, ldap-pam meg hasonlok, minden, aminek koze lehet hozza, purge aldozata lett :)
Aztan kezzel toroltem a /var/lib/ldap tartalmat. Es nekialltam ujra telepiteni, letrehozni, egyeb. Es ugy tunik, mukodik :) Eccoval, nem tudom, mi volt a gebasz, de az egeszet elolrol kezdve muxik. Vszinuleg
eroszakot kovettem el az ldap-on, amikor minden tiltakozasa ellenere valahogy letrehoztam a rootdn-t :)))

Namost, kifogtam eletem talan legszebb windows-hibauzenetet :)
SAMBA-LDAP, workgroup szepen mukodott, most a domain-alaput probaltam, ez alapjan:
http://www.nomis52.net/?section=docs&page=samldap
Nagynehezen rajottem, hogy a "machines" szekcioban a gepek neve vegere egy "$" jel kell, igy a gepet be tudom leptetni a domain-be.
Viszotn amikor a gepen userkent akarok belepni a domain-be, akkor jon a csodalatosan semmitmonmdo:
(angol w2k): the system cannot find message text for message number 0x%1 in the message for %2
Ugyanez megvan magyar xp-n is :))))
A legjobb, hogy szo szerint beirva a google-ba, tobbszaz talaltot kaptam ra :) Ha rajovok, mi a gond (MS honlap valami SmartCard-ot emleget...), megirom. De jelenleg annyira teccik a hibauzi, hogy bemasoltam :)

Ez megoldodott.
http://www.nomis52.net/?section=docs&page=samldap
Ezen az oldalon hibas a leiras PAM-resze.

/etc/pam.d/common-account

# Comment out the next line #account required pam_unix.so
# and add these two
account sufficient pam_ldap.so account required pam_unix.so try_first_pass

/etc/pam.d/common-auth

# comment out the next line #auth required pam_unix.so nullok_secure
# and add these two
auth sufficient pam_ldap.so
auth required pam_unix.so nullok_secure use_first_pass

/etc/pam.d/common-password

# comment out the next line
#password required pam_unix.so nullok obscure min=4 max=8 md5
# and add these two
password sufficient pam_ldap.so
password required pam_unix.so nullok obscure min=4 max=8 md5 use_first_pass

Vmelyik bejegyzes nem jo, ha jol remlik, akkor az auth-nal a try_first_pass a bibi. Koszonom Pere Laszlo konyvet, amiben gyonyoruen leirja a PAM mukodeset es opcioit :)

Egyebkent a Debianos libpam-ldap is irja a doksijaban, hoyg kepes hibas mukodesre, ha valaki ezzel szorakozik, olvassa el a doksit! (Asszem, readme.debian az /usr/share/doc/libpam-ldap directory-ban)

Update: megneztem, a
password required pam_unix.so nullok obscure min=4 max=8 md5 use_first_pass
vegere nem kell (es nem is szabad) a use_first_pass

Nem akarom elkiabalni, de mukodik :))))
Ezer hala, nagyon koszonom, terdre borulok, meg minden :)
A jelek szerint itt volt a bibi:
objectClass: top
Vagyis ezt _nem_ szabad a gyokerbe tenni (en meg talan ezt nem vettem ki egyedul, azt hiven, hogy a gyokeret jelenti...)
Vagyis ez mar jo:

dn: dc=test
objectClass: dcObject
objectClass: organization
dc: test
o: CegLDAP

dn: cn=Manager,dc=test
objectClass: organizationalRole
objectClass: top
cn: Manager

dn: cn=admin,dc=test
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: admin
description: LDAP administrator
userPassword: {SSHA}

#d) Userek
dn: ou=People,dc=test
objectClass: organizationalUnit
ou: People

#e) Csoportok
dn: ou=Group,dc=test
ou: Group
objectClass: top
objectClass: organizationalUnit

#f) Mail aliasok
dn: ou=MailAliases,dc=test
ou: MailAliases
objectClass: top
objectClass: organizationalUnit

A jelszavakkal sincs gondja, a fenti strukturat tokeletesen letrehozta, most majd probalkozok a sajat gyartasu OE ldif-ek importalasaval. Es ezt Neked koszonhetem, aldassek a Te neved, Panther :)
Koszi!

(Azert felek, hogy nem lesz ilyen egyszeru, ha megint nem jutok egyrol a kettore, megint erdeklodok :) De remelhetoleg most mar a leirasok alapjan vegigvergodok rajta.)

Jaigen, az volt afurcsa, hogy amit exportaltam, abban benne volt a top....Lehet, hogy ezert nem mukodott a tobbi felvitele sem.
Most exportalom a fat phpldapadmin-ban, a gyoker bejegyzesben mar nincs top, csak az Admin-ban.
Na, munkara, aztan meglatjuk :)

Na, beleugrott a majom a vizbe, es kozben becsinalt a halott...
Kiindulva abbol, amit Te adtal, ezt tettem:

xx.ldif tartalma:
dn: ou=AdressBook,dc=test
ou=AdressBook
objectClass: top
objectClass: organizationalUnit

(Aztan kiszedtem a topot is)

A felvitel:
ldapadd -f xx.ldif -vxD cn=admin,dc=test -W 1> xx.log 2>&1

xx.log tartalma:
ldap_initialize( <DEFAULT> )
ldapadd: invalid format (line 2) entry: "ou=AdressBook,dc=test"

(Es probaltam szokozt hagyni sor vegen, entert 2x meg a dos2unix es unix2dos proggit is bevetettem)
Ecceruen nem hozza letre.... Segithet esetleg a slapd.log tartalma?

Aztan duhomben a phpldapadmin segitsegevel probalkoztam, es minden tovabbi nelkul letrehozta...
Na, megyek, megprobalok masik ou-t legyartani, de ha az sem sikerul...
Nemnemnem, nem akarok kezzel felvinni 384756 darab cimet :((((

Halas lennek, ha meg ebben is tudnal segiteni, de ha nem, akkor is koszi az eddigiekert!

UPDATE: Nemigaz, hogy ennyiszer tudok ilyen marha lenni, elnezest :(
Megint elneztem, hova kell kettospont es hova egyenlosegjel :((((

Bocsi, targytalan az egesz, megyek, hamut szorok a fejemre...

:))))
Ez a lustasag atka, ha az ember F3-mal masol mc-ben :)
Gepelni kell, a szentsegit, ha beleszakadok is :)
Vegulis, teljesen logikus, csak atsiklik folotte a szemem...

[quote:e2ea3dbd7a="Panther"][quote:e2ea3dbd7a="Celtic"]
xx.ldif tartalma:
dn: ou=AdressBook,dc=test
ou=AdressBook
objectClass: top
objectClass: organizationalUnit

ou: Addressbook

nincs egyenlőség, csak kettőspont. Igen, a unix világ következetes: hol így, hol úgy....

Naigen, ACL a gond. Toroltem az osszes ACL bejegyzest, es mukodik. Persze, igy nem maradhat, de mar az valami, hogy mukszik :)
Lennei s ezzel kapcsolatban kerdesem:
slapd.conf idevonatkozo sorai:

backend bdb
checkpoint 512 30
database bdb
directory "/var/lib/ldap

index objectClass,uidNumber,gidNumber eq
index cn,sn,uid,displayName pres,sub,eq
index memberUid,mail,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass
by self write
by anonymous auth
by * none
by * read
access to *
by * read

Vagyis, itt az ACL-ek a datatabase/backend beallitason _belul_ vannak. Kesobb kimasoltam oket, rogton a schema-include utan. A log file-ok:
(Megint csak a lenyegest masolom ide: )

1 09:41:09 test slapd[28089]: line 40 (access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass)
Feb 1 09:41:09 test slapd[28089]: line 41 (by self write)
Feb 1 09:41:09 test slapd[28089]: /etc/ldap/slapd.conf: line 41: unknown directive "by" outside backend info and database definitions (ignored)
Feb 1 09:41:09 test slapd[28089]: line 42 (access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass)
Feb 1 09:41:09 test slapd[28089]: line 43 (by anonymous auth)
Feb 1 09:41:09 test slapd[28089]: /etc/ldap/slapd.conf: line 43: unknown directive "by" outside backend info and database definitions (ignored)
Feb 1 09:41:09 test slapd[28089]: line 44 (access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass)
Feb 1 09:41:09 test slapd[28089]: line 45 (by * read)
Feb 1 09:41:09 test slapd[28089]: /etc/ldap/slapd.conf: line 45: unknown directive "by" outside backend info and database definitions (ignored)
Feb 1 09:41:09 test slapd[28089]: line 46 (access to *)
Feb 1 09:41:09 test slapd[28089]: line 47 (by * read)
Feb 1 09:41:09 test slapd[28089]: /etc/ldap/slapd.conf: line 47: unknown directive "by" outside backend info and database definitions (ignored)
Feb 1 09:41:09 test slapd[28089]: line 51 (access to attrs=userPassword by dn="cn=root,dc=test" write by anonymous auth by self write)
Feb 1 09:41:09 test slapd[28089]: >>> dnNormalize: <cn=root,dc=test>
Feb 1 09:41:09 test slapd[28089]: <<< dnNormalize: <cn=root,dc=test>
Feb 1 09:41:09 test slapd[28089]: line 52 (by * read)
Feb 1 09:41:09 test slapd[28089]: /etc/ldap/slapd.conf: line 52: unknown directive "by" outside backend info and database definitions (ignored)
Feb 1 09:41:09 test slapd[28089]: line 55 (access to * by dn="dc=test" write by * read)
Feb 1 09:41:09 test slapd[28089]: >>> dnNormalize: <dc=test>
Feb 1 09:41:09 test slapd[28089]: <<< dnNormalize: <dc=test>
Feb 1 09:41:09 test slapd[28089]: line 60 (backend ^Ibdb)
Feb 1 09:41:09 test slapd[28089]: line 61 (checkpoint 512 30)
Feb 1 09:41:10 test slapd[28089]: line 67 (database bdb)
Feb 1 09:41:10 test slapd[28089]: bdb_db_init: Initializing BDB database
Feb 1 09:41:10 test slapd[28089]: line 69 (suffix "dc=test")
Feb 1 09:41:10 test slapd[28089]: >>> dnPrettyNormal: <dc=test>
Feb 1 09:41:10 test slapd[28089]: <<< dnPrettyNormal: <dc=test>, <dc=test>
Feb 1 09:41:10 test slapd[28089]: line 70 (rootdn ^I"cn=admin,dc=test")
Feb 1 09:41:10 test slapd[28089]: >>> dnPrettyNormal: <cn=admin,dc=test>
Feb 1 09:41:10 test slapd[28089]: <<< dnPrettyNormal: <cn=admin,dc=test>, <cn=admin,dc=test>
Feb 1 09:41:10 test slapd[28089]: line 71 (rootpw ***)
Feb 1 09:41:10 test slapd[28089]: line 75 (directory "/var/lib/ldap")
Feb 1 09:41:10 test slapd[28089]: line 83 (lastmod on)
Feb 1 09:41:10 test slapd[28089]: line 96 (access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass)
Feb 1 09:41:10 test slapd[28089]: line 97 (by self write)
Feb 1 09:41:10 test slapd[28089]: /etc/ldap/slapd.conf: line 97: unknown directive "by" inside backend database definition (ignored)
Feb 1 09:41:10 test slapd[28089]: line 98 (access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass)
Feb 1 09:41:10 test slapd[28089]: line 99 (by anonymous auth)
Feb 1 09:41:10 test slapd[28089]: /etc/ldap/slapd.conf: line 99: unknown directive "by" inside backend database definition (ignored)
Feb 1 09:41:10 test slapd[28089]: line 100 (access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass)
Feb 1 09:41:10 test slapd[28089]: line 101 (by * read)
Feb 1 09:41:10 test slapd[28089]: /etc/ldap/slapd.conf: line 101: unknown directive "by" inside backend database definition (ignored)
Feb 1 09:41:10 test slapd[28089]: line 102 (access to *)
Feb 1 09:41:10 test slapd[28089]: line 103 (by * read)
Feb 1 09:41:10 test slapd[28089]: /etc/ldap/slapd.conf: line 103: unknown directive "by" inside backend database definition (ignored)
Feb 1 09:41:10 test slapd[28089]: line 107 (access to attrs=userPassword by dn="cn=root,dc=test" write by anonymous auth by self write)
Feb 1 09:41:10 test slapd[28089]: >>> dnNormalize: <cn=root,dc=test>
Feb 1 09:41:10 test slapd[28089]: <<< dnNormalize: <cn=root,dc=test>
Feb 1 09:41:10 test slapd[28089]: line 108 (by * read)
Feb 1 09:41:10 test slapd[28089]: /etc/ldap/slapd.conf: line 108: unknown directive "by" inside backend database definition (ignored)
Feb 1 09:41:10 test slapd[28089]: line 111 (access to * by dn="dc=test" write by * read)

Vagyis egyszer az volt a baja, hogy inside, kesobb az, (miutan elore tettem), az, hogy outside. A "by" nem teccik neki. Ennek oomere kitoroltem az osszeset, es mukodik. Ezekutan azt nem tudom, vajon az "ignored" sorok tenyleg "figyelembe nem vett" sorok voltak, vagyis azok hianya okozta, hogy nem tudtam bejelentkezni vagy netan azokban volt a hiba, es torles utan "megjavult". En mondjuk az elso esetre tippelek. Csak azt nem tudom, miert lettek "ignored", miert nem fogadta el.

Najo, holnap tovabb folytatom, nincs kedvem megint nyolcig maradni :)
Azzal a megnyugtato tudattal megyek haza, hogy az alapok mar mennek, a tobbit majd legkozelebb (OE es Mozilla adressbookok importalasa scriptbol)
Talan az is sikerul...Hiaba, ha egyszer a szanko beindul :)

Nos, Debian testing, mint emlitettem volt, a slapd verzioja meg igen erdekes :)
@(#) $OpenLDAP: slapd 2.2.26 (Oct 31 2005 09:10:53) $
@pulsar:/home/torsten/packages/openldap/openldap2.2-2.2.26/debian/build/servers/slapd

(Fogggalmam sem van, ki az a torsten, es milyen forditas ez. Lehet, hogy nem hivatalos? Majd korbenezek a Debian lapon)
Masik izgalmas, hogy baromira nem volt ecceru kinyerni a fentit, mindenaron kepernyore irt, atiranyitas nem mukodott. Szerencsere a
nohup slapd -V
parancsot mar nem tudta kikerulni...

UPDATE: oke, megneztem, ugy tunik, Torsten tartja karban a Debian-nal az LDAP-ot.

Es jo es mukodik es koszi :)
Lenne egy kerdesem: magyar ekezetes nevek felvihetok valahogy?
Sajna, ha magyar ekezet szerepelt a cn-ben, fel sem vitte a bejegyzest.
(Ha maskent nem megy, atalakitom az osszeset, csak jobb lenne a userek miatt, ha ekezetes lenne)
Aztan meg visszavan az osszes user cimlistajanak felvitele meg az eleresek beallitasa, de azokon remelhetoleg mar tul fogok jutni egyedul is :)

Kosz, egy kis idobe telt, mire hozza tudtam adni, de semmi sem valtozott.
Vagyis ugyanugy nem enged be, az auth.log-ban ua a ket hiba szerepel.
Mindegy, majd hetfon ujult erovel.

[quote:2f05298b91="Panther"]Jelszó@ shadowAccount objClass?
(tudtommal, mivel kerberost használok)

Hmm, asszem kozben az elso gondom megoldodott. Probakeppen installtam egy egroupware-t, az minden tovabbi nelkul fogadja az OE-fele csv-t es gond nelkul menti ldif-be :)

Es amit nem mondtam (ugy latszik, atfutottam felette), ha a slapd-t restartolom, ezt irja az auth.log (!) file-ba:
an 27 18:34:16 test slapd[19883]: sql_select option missing
Jan 27 18:34:16 test slapd[19883]: auxpropfunc error no mechanism available
Jan 27 18:34:16 test slapd[19883]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

Hmm, kivancsi lennek, miert ir az auth.log-ba ujrainditaskor. Es milyen sql a bibije, mikor BDB3 az adatbazis...

Akkor megegyzser koszi, majd irok ra egy tr-scriptet.
(vagy nekiallok sed-et megtanulni :)I

[quote:57d011a37a="Panther"][quote:57d011a37a="Celtic"]Es jo es mukodik es koszi :)
Lenne egy kerdesem: magyar ekezetes nevek felvihetok valahogy?

cn, gecos kivételével bárhol lehet. Nálam úgy is van.

Haliho!
Hosszu lesz...Egy honapja kaptam feladatkent, hogy allitsak be egy LDAP-szervert. Jo, hat ilyet meg nem csinaltam, ugorgyunk :) neki.
slapd meg a hozzatartozo cuccok telepit, es ha szabadidom volt, akkor szorakoztam vele.
Rendszer:
Belso halon logo Debian testing, 2.6.13-4 kernel, slapd 2.2.26, ldap-utils felrakva.
Nos, eloszor is, megcsinaltam az /etc/ldap/slapd.conf filet

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

#######################################################################
# Global Directives:

# Features to permit
#allow bind_v2
allow bind_anon_dn
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/outlook.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/misc.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
readonly off
schemacheck on
password-hash {MD5}

#### ITT MAR EN SZURTAM BE, ERDETILEG NEM VOLT password-hash

loglevel 4095
#logfile /var/log/slap.log
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_bdb

backend bdb
checkpoint 512 30

#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
backend bdb
#The base of your directory in database #1
suffix dc=ceg,dc=hu
#suffix "o=test.ceg.hu"
rootdn cn=root,dc=ceg,dc=hu
#rootdn "cn=root,o=test.ceg.hu"
rootpw admin
#rootpw {crypt}x5csu0pj96YIU
#rootpw {SSHA}1MG3Nu/St4+YGaszUJGcanBTVsehZWV+
#rootpw {MD5}ISMvKXpXpadDiUoOSoAfww==

# Where the database file are physically stored for database #1
#directory "/var/lib/ldap"
directory "/var/lib/ldap/ceg"

# Indexing options for database #1
index objectClass eq

# Save the time that the entry gets modified, for database #1
lastmod on

# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword
by dn="cn=root,dc=ceg,dc=hu" write
# by dn="cn=root,o=test.ceg.hu" write
by anonymous auth
by self write
by * none

# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
# by dn="cn=admin,dc=test,dc=ceg,dc=hu" write
by dn="dc=ceg,dc=hu" write
# by dn="o=test.ceg.hu" write
by * read

# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=test,dc=ceg,dc=hu" write
# by dnattr=owner write

#######################################################################
# Specific Directives for database #2, of type 'other' (can be bdb too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>

# The base of your directory for database #2
#suffix "dc=debian,dc=org"

Mint laccik, sok mindennel probalkoztam :)
Eloszor is, elvileg letrehozta ceg.hu dn-t (vagyis dc7ceg,dc=hu), de nem tudtam bele irni a Linuxos ldapadd, ldapmodify cuccokkal. Ekkor windowshos fordultam, Mozillal, phpldapadmin. Ott ugyanez. vegulis asszem a jxplorer 3.1 nevu java-s proggival sikerult felvinnem cuccokat.
Ezutan mar phpldapadmin segitsegevel, jxplore segitsegevel is tudtam felvinni, de ugye a cel az lenne, hogy xy lementi ldif-be a cimjegyzeket, ezt pedig az ldapadd hozzaadja. De nem es nem, ldapadd Naming violation meg hasonlo uzenetekkel elment. Ekkor ugrott be, hogy esetleg jelszo gond... (Eddigre mar a magyar nyelvu ldap-leirasokkal vegeztem). Elkezdtem a forumokat (hup), levlistakat (mlf.linux.rulez.org) olvasgatni, a hibauzire keresve (ldap-ra egy kicsit sok talaltot adott volna a google:)

Nos, mint kiderult, en normal titkositast probaltam (crypt), ami nincs az LDAP-ban. SASL-on keresztul probalkozik. A SASL pedig MD5-DIGEST kodolassal. Ezert vannak a slapd.conf-ban a kulonfele passwd cuccok.
Tegnap este az egyik mlf-es iras alapjan arra jutottam, hogy megnezzem az alabbi paranccsal, milyen hitelesites van:
ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms

Eredmeny:
dn:
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5

Hmm, hat ez nem a legjobb, de legalabb ertem, miert akar mindenaron DIGEST-MD5-on azonositani.
Szoval megprobalok felvinni legalabb egy root-ot, mivelhogy azt sem latja.

#ldapadd -f dia.ldif -v 1> dia.log 2>&1
ldapadd -f alap.ldif -v -w admin 1> dia.log 2>&1
#ldapmodify -c -f cimekotthon.ldif -xv -D "cn=admin,dc=test,dc=aion,dc=hu" -w admin 1>cimekotthon.log

Ha a -w nincs, akkor ugye jelszot ker, es igy tunt fel, hogy DIGEST-MD5, mig a phpldapadmin importjaban CRYPT szerepel.
alap.ldif tartalma:

dn: dc=test,dc=ceg,dc=hu
objectClass: top
objectClass: dcObject
objectClass: organization
o: ceg
#structuralObjectClass: organization
#entryUUID:
#creatorsName: cn=anonymous
#modifiersName: cn=anonymous
#createTimestamp:
#modifyTimestamp:
#entryCSN:
#subschemaSubentry: cn=Subschema
#hasSubordinates: TRUE

Mindnek volt erteke, csak toroltem. Egyebkent import, de ahogy sorban nem olvasta be, ugy kommenteztem ki.
Probaltam az
objectClass: organization
o: ceg
sorokat is kommentezni, de az se segit.

Nos, amivel eccer, veletlenul sikerult letrehoznom, es akkor csinaltam szep importot, ezt most ide bemasolom. term. azota ujra nem tudom letrehozni, es akkor sem tudtam felvinni bejegyzest, csak phpldapadmin, jxplorer vagy ldapadmin 0.9.8.6a segitsegevel. (elso bongeszos, php alapu, masodik java-s exe, harmadik tisztan exe, szoval windows :)

Ez volt a felig-mukodo:
version: 1

# A(z) dc=test,dc=ceg,dc=hu LDIF exportja
# A phpLDAPadmin generálta, dátum: December 19, 2005 3:20 pm
# Kiszolgáló: My LDAP Server (localhost)
# A keresés hatásköre: sub
# Keresőszűrő: (objectClass=*)
# Bejegyzések száma összesen: 3

# Bejegyzés 1: dc=test,dc=ceg,dc=hu
dn: dc=test,dc=ceg,dc=hu
objectClass: top
objectClass: dcObject
objectClass: organization
o: ceg.hu
dc: test
structuralObjectClass: organization
entryUUID:
creatorsName: cn=anonymous
modifiersName: cn=anonymous
createTimestamp: 20051219081049Z
modifyTimestamp: 20051219081049Z
entryCSN:
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE

# Bejegyzés 2: cn=admin,dc=test,dc=ceg,dc=hu
dn: cn=admin,dc=test,dc=ceg,dc=hu
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword: {crypt}x5csu0pj96YIU
structuralObjectClass: organizationalRole
entryUUID: b5f3b68c-04b2-102a-998d-abdc99e16069
creatorsName: cn=anonymous
modifiersName: cn=anonymous
createTimestamp:
modifyTimestamp:
entryCSN:
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE

# Bejegyzés 3: cn=Celtic,cn=admin,dc=test,dc=ceg,dc=hu
dn: cn=Celtic,cn=admin,dc=test,dc=ceg,dc=hu
givenName: celtic
sn: celticovits
street: xx
o: ceg Kft.
l: Budapest
st: Hungary
postalCode: 0000
telephoneNumber:
mobile:
mail:
objectClass: inetOrgPerson
objectClass: top
structuralObjectClass: inetOrgPerson
entryUUID:
creatorsName: cn=admin,dc=test,dc=ceg,dc=hu
createTimestamp: 20051219091309Z
cn: Celtic
entryCSN:
modifiersName: cn=admin,dc=test,dc=ceg,dc=hu
modifyTimestamp:
subschemaSubentry: cn=Subschema

-----------------------------------------------------------------------
Nos, azota magat a root dn-t sem tudom letrehozni :(
jaigen, term. /var/lib/ldap/ceg letezik, irhato es irja is.

Mint emlitettem, jopar levlistat es forumot atbongesztem, nehany helyen azt ajanljak, forditsa ujra az ember az ldap-ot, hat lehet, hogy az lesz a vege....Meg kiprobalom otthon, az unstable alatt hetvegen, aztan meglatom. Igaz, ha ldap-ot forditok, akkor elotte sasl-t es Berkeley db-t is fordithatok. Megis jobban orulnek, ha valaki tudna vmi megoldast :)

(Ha kihagytam valami relevans infot, szoljatok, sztem ennyi eleg, sot sok is :)
Nagyon koszonom, ha valaki erdemi valasszal megtisztel, mielott teljesen megoszulok....

Es megeccer bocs a meretert, csak gondoltam, inkabb tobbet irjak, mint kevesebbet (elvegre nem vagyok PP :)

Hat, en altalaban meg inkabb ertem, mint a windowst :)
A deb-src-ben sztem benne van, milyen kapcsolokkal forgattak a cuccost.
Majd letoltom.
Ha nincs ott a konyvtar, akkor letrehozza. Probaltam.
Hmm, a tulaj jogait nem neztem.

Naigen, a jelszavak...Fogalmam sincs, hogy mukodik-e vagy nem :(
Nem tudom, hogy eppen anonymous-kent vagyok belepve vagy admineknt :(
Nezegettem a slapd.log-ot (vagyis a local3-at), de attol sem lettem okosabb :(

Egyebkent az egesz egy honapnyi szenvedes eredmenye, szoval azert iylen zavaros. Meg azert, mert pentek este van es inkabb hazamennek :)
El is indulok, talan meg hetfoig lesz otlet...
Hatigen, nincs user vagy group ldap neven. Majd hetfon letrehozom.
koszi az eddigieket is, remelm, meg par otelt beesik hetfoig :)
(Csak nehogy otthon is nezegessem a topicot es elpattanjon valami, aztan szombat vagy vasrnap alkalmabol berohanjak melohelyre :)

[quote:8652362523="Panther"]Ezt utálom a debianban. Halvány sejtelmem sincs, mit csinál.

Nos, akkor fapados megoldás, ne legyen ott az a /var/lib/ldap/ceg könyvtár, vagyis nevezd át és hozzál létre üreset ldap/ldap tulajjal, vagy értelemszerűen.

Utána a fa gyökerét szúrd be, és biztosan menni fog.

A jelszavakkal meg most mi is a gond? Működik? Nem működik? ???

Probaltam az u:admin es d:dc= meg hasonlok modokat is.
Hogy oszinte legyek, ebben a ket cuccban windows altt (sot, a phpldapadminban is) _nem_ irta sehol, hogy milyen csatlakozast valasztok, ergo nem is valaszthattam...
Namindegy, asszem hetfon forgatas lesz.

[quote:ffe103bef3="Panther"]ldapsearch -x: anonymous
ldapsearch -D... => nevesítve.

nss-ldap-ban is hasonlóan megadható. Neked ldapmodify -aWD cn=root, cn=... -f fájlnév kell lértehozáskor, mint elkövetted. Egyébként szerintem jobb kerberosban tárolni a jelszavakat.

Ja, persze minden kliens programban megadható, hogy hogyan csatlakozol, tehát kellene tudnod.

Koszi, akkor ezzel nem foglalkozok. Valahol a pam kornyeken lesz a bibi. Esetleg nem jo rootbinddn vagy ilyesmi lesz megint. nsswitch jo, hiszen a getent (ha jol emlekszem a nevere) megtalalja az usert/groupot. Ha _be akarok lepni_ vagyis a pam konyeken halodik meg. Na, majd hetfon, ujult erovel :)

[quote:f325a73e1d="Panther"][quote:f325a73e1d="Celtic"]Es amit nem mondtam (ugy latszik, atfutottam felette), ha a slapd-t restartolom, ezt irja az auth.log (!) file-ba:
an 27 18:34:16 test slapd[19883]: sql_select option missing
Jan 27 18:34:16 test slapd[19883]: auxpropfunc error no mechanism available
Jan 27 18:34:16 test slapd[19883]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

Hmm, kivancsi lennek, miert ir az auth.log-ba ujrainditaskor. Es milyen sql a bibije, mikor BDB3 az adatbazis...

Nekem is ír ilyet, de működik...

Na, jovok az ujabb kinjaimmal :)
Az egy dolog, hogy Outlook-bol CSV-ben kiszedett cuccot nem tudok ldifre alakitani a csv2ldif.pl segitsegevel (sajna, nem tudom, honnan szedtem, csak a fejlecet tudom beidezni, lenyeg, hogy nem alakitja at)

#!/usr/bin/perl
#
# This is an example of using the Text::ParseWords module to convert
# a comma-delimited file to LDIF. Requires Perl 5.005 or higher. Just
# pipe the CSV file to this script and redirect the output to a file:
#
# cat FILENAME.csv | csv2ldif.pl > FILENAME.ldif
#
# Anthony Greene <agreene@pobox.com>
#
# This version modified for the fields used by MS Outlook 98 by
# Buchan Milne <bgmilne@cae.co.za> 20011002
#

Ha erre tud valaki megoldast, nagyon orulok :)
Ha esetleg fontos a hibauzi is vagy az egesz perl kod, szivesen beidezem, de csak holnap :)

Nagyobb gondom, hogy sambat akarok authentikalni (szepen, magyarosan :)

Talaltam is jopar oldalt itt a HUP-on, ami leginkabb megragadott, az ez:
http://www.nomis52.net/?section=docs&page=samldap
(Mar nem tudom, melyik forumban emlitettek.)
Szepen haladtam, par buktaton atestem (getent nem talalt senkit az ldap-bol, persze megint nem adtam meg a libnss-ldap vagy a pam_ldap file-ban a rootdn-hez az utat. Szoval addig oke, hogy getenv megtalalja az openldap-ban a felvitt groupokat es usereket. Viszotn ha be akarok lepni konzolon, semmi modon nem enged be. slapd log-jat nezve kikeresi az usert, aztan megis nullat ad vissza. Ha nem SambaAccont-kent viszem fel, hanem PosixAccount, akkor legalabb a nevet visszaadja, de igy sem talal hozza passt.

Jaigen, az ldap felepitese nagyvonalakban ez:

- img dc=test (6)
+ img cn=Manager
+ img cn=admin
+ img cn=sproba
- img dc=samba (4)
- img ou=groups (3)
+ img cn=admins
+ img cn=guests
+ img cn=users
új Új bejegyzés
+ img ou=machines
- img ou=users (3)
+ img cn=Admin
+ img cn=attila
+ img cn=normal
új Új bejegyzés
+ img sambaDomainName=TEST
új Új bejegyzés
+ img ou=AddressBook (15)
+ img sambaDomainName=TEST

Tehat ha a "normal" vagy "attila" userekkel akarok belepni, akkor az elejen levo hiba jon (Samba.schema-val lettek letrehozva), ha az sproba nevu userrel (ami PosixAccount), akkor a masodik hiba.
Mellekelve az auth.log, itt latszanak a hibak

Jan 26 19:30:23 test login[3207]: (pam_unix) check pass; user unknown
Jan 26 19:30:23 test login[3207]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=tty5 ruser= rhost=
Jan 26 19:30:26 test login[3207]: FAILED LOGIN (1) on `tty5' FOR `UNKNOWN', User not known to the underlying authentication module
Jan 26 19:30:30 test login[3207]: (pam_unix) check pass; user unknown
Jan 26 19:30:30 test login[3207]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=tty5 ruser= rhost=
Jan 26 19:30:34 test login[3207]: FAILED LOGIN (2) on `tty5' FOR `UNKNOWN', User not known to the underlying authentication module
Jan 26 19:30:41 test login[3207]: FAILED LOGIN (3) on `tty5' FOR `sproba', Authentication service cannot retrieve authentication info.

Nos, remelem, tud valaki segiteni (ha meg tudok valamit mellekelni, szoljatok), de en most megyek haza, kicsit kifaradtam, es elnezest, ha zavarosra sikerult.

Hehe, kicsit up-olom, hatha hetfo alkalmabol van valakinek otlete, vagy belefutott ilyesmibe...

O, az egyik ki volt rem-elve (#) :)
Mas, sokkal nagyobb gond van, ugy tunik.
Most biztos kirohogsz, de ugy latom, az en ldap-verziom csak ugy fogadja el, ha igy irom
access to attrs=userPassword,sambaLMPassword,sambaNTPassword,objectClass by self write by anonymous auth by * none by * read access to * by * read

Szoval nem tudom, atmegy-e, de total egy sorban az "access to"-t a "by" direktivakkal :(
Nem ertem, tenyleg vmi gond van az ldap-verziommal, vagy ez az uj modi vagy mi a fittyfene... Vagy nem "enter" kellene a sor vegere, hanem a nyavalya tudja, micsoda :(

[quote:2f4a1e735d="Panther"]Ha jól értem ez a két sor nem jó:
by * none
by * read

Ha mindenki másnak nem adsz rá semmilyen jogot, akkor miért akarsz utána olvasási jogot adni? Másképpen: ha már megadtál egy "felhasználócsoportnak" egy jogosultságot, akkor azt nem lehet felülbírálni, és az ismétlődés hibának vehető. Úgy tűnik, az ldap annak veszi.

A többi szerintem jó.

Jelen pillanatban az otthoni gepem elott ulok.
Itt a hostname: celtic.no-ip.org
Elhoztam a ceges cuccokat, megprobalom feltenni.
phpldapadmin ezt irja:
My LDAP Server
( séma | keresés | frissítés | infó | import | export | kilépés )
Belépve mintcn=root,dc=ceg,dc=hu,
? dc=no-ip,dc=org
This base entry does not exist. Create it?

Innen kezdve vki tudna segiteni? Mondjuk, azt sem ertem, miert no-ip.org a dc, miert nem ceg.hu? Esetleg a dc-t a hostname-bol vette?
(Egyebkent ugyanez jatszodott le a cegnel is, mikor valtottam a rootdn-en, a gep host nevebol vette a dc-t. Ez normalis dolog? )
Szoval, innen kernek segitseget, hogy a gyokeret letre tudjam hozni, lehetoleg dc=ceg,dc=hu formatumban. A tobbit majd utana :)
Probalkozasaim (mindig a Cretae it?-re kattintva):
Első lépés:
Név és objektumosztály(ok)
RDN: dc=no-ip,dc=org (példa: cn=ÚjEmber)
Tároló _______________ böngészés
Objektumosztályok
(itt szep lista van)
Mit irjak RDN-be? Mit a taroloba?
(Gondoltam, tarolo a dc=ceg,dc=hu ,dehatperszehogyne az istennek sem fogadja el :(

Gondoltam, kiprobalom a dcobject objektumosztalyt
(probaltam dc=ceg; dc=ceg,dc=hu;dc=celtic;dc=celtic.,dc=no-ip,dc=org meg az osszes lehetseges formatumban)

Hiba:

Hiba
Nem tudom az objektumot létrehozni a kiszolgálón.

Az LDAP ezt mondta: Server is unwilling to perform
Hibaszám: 0x35 (LDAP_UNWILLING_TO_PERFORM)
Leírás: The LDAP server refused to perform the operation.

Koszi, maris tudom, mi a gond :(
(Megjegyzem, a fenti hibauzire kerestem a googlen, igy talaltam pl. az mlf listajat is)

A masik hibauzit, amit kaptam( csak fejbol), vmi Naming violation...

Szoval, ha valaki abban segitene, hogy mit irjak be a phpldapadmin-nak, hogy a root-bejegyzest letrehozza, mar nagyon sokat segitene rajtam :)

Ezer hala erte! Mindjart olvasgatom. Kozben rajottem, phpldapadmin eseten miert mas a nev: beirtam a config.php-ba. De hogy mikor es miert? Sajnos, felvinni ( a rootot eloszor is) azota sem sikerult, semmilyen modon. De mindjart megnezem a doksidat, csak most megitn riasztottak, vmelyik OE megen nem mukszik :(

[quote:aefa1a51a8="Panther"]Azért nem írtam semmit, mert nincs 5letem. Neten van howto, és nekem sikerült beizzítani egy ldap servert ( http://cfhay.inf.elte.hu/~panther/linux/ alatt megtalálod, amit összehoztam).

Sajna, pingelni sem lehet a cfhay.inf.elte.hu cimet. :(

[quote:5e45846360="Panther"]http://cfhay.inf.elte.hu/~panther/linux/

Oke, koszi. Pingelni azutan probaltam, hog yhttp-n nem jott be.

Beerek a ceghez, megirom a verziot.
Egyebkent Debian testing.
Tudtam, hogy hihetetlen lesz, hoyg nem irhatom egymas ala, de tenyleg ez tunt az egyetlen mukodo megoldasnak (nem tiltakozott a "by" direktivak kulon szerepeltetese ellen), es igy vegre beenged. Amugyis be kellett egyszer allitanom az ACL-eket az emiles cimtarhoz. De hoyg ennek most jott el pont az ideje... :)
Egyebkent FAQ szerint "whitespace", ami emlekeim szerint szokoz, tab, enter lehet. Namost, ENTER megsem lehet, ugy tunik.
Egyebkent lehet, hogy egy apt-get update/upgrade megoldana a porblemat...

[quote:b9b001e783="Panther"]Nálam így van
[code:1:b9b001e783]
access to attr=userPassword
by dn="cn=admin,dc=panthernet" write
by anonymous auth
by self write
by * none
[/code:1:b9b001e783]
Lehetne egy sorban is, de minden access külön sorban. Na de hogy így nem írható, az tényleg lol. Fura egy ldapod van.

Ja, verzió.
* net-nds/openldap
Latest version installed: 2.2.28-r3