2012. október 31., szerda

Kapcsolati felhasználók PAM-hoz, Samba-hoz és Kerberos-hoz Ubuntu 12.04-en

Jelen pillanatig az OpenLDAP-szerverünk ACL-je a következő (vastaggal a parancs, a többi a kimenet):
sudo ldapsearch -Q -LLL -Y EXTERNAL -b cn=config '(olcDatabase={1}hdb)' olcAccess
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn="cn=
 admin,dc=itthon,dc=cucc" write by * none
olcAccess: {1}to attrs=shadowLastChange,shadowMax by self write by dn="cn=admi
 n,dc=itthon,dc=cucc" write by * read
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by self write by dn="cn=admin,dc=itthon,dc=cucc" write by *
  read
A by * read nem olyan szép. Ezen és másokon változtatunk ma.
(You can read this article in English too.)
Ha még emléxünk, annak idején az LDAP-kliens telepítésekor azt mondtuk, hogy:
Does the LDAP database require login? No
Na, ezt nem gondoltuk komolyan:)
Szerkesszük az /etc/ldap.conf állományt a kliensen - tegyünk bele két ilyen sort:
binddn cn=pamproxyuser,ou=serviceAccounts,dc=itthon,dc=cucc
bindpw nagytitok
Az LDAP-szerveren pedig hozzunk létre két fájlt. A serviceaccountsou.ldif tartalma:
dn: ou=serviceAccounts,dc=itthon,dc=cucc
objectClass: top
objectClass: organizationalUnit
ou: serviceAcoounts
description: nem valos felhasznalok
Adjuk hozzá az LDAP-hoz:
ldapadd -D cn=admin,dc=itthon,dc=cucc -w titok -f serviceaccountsou.ldif
A pamproxyuser.ldif tartalma:
dn: cn=pamproxyuser,ou=serviceAccounts,dc=itthon,dc=cucc
objectClass: applicationProcess
objectClass: simpleSecurityObject
cn: pamproxyuser
userPassword: nagytitok
description: proxyuser PAM ldap bind
Adjuk hozzá az LDAP-hoz:
ldapadd -D cn=admin,dc=itthon,dc=cucc -w titok -f pamproxyuser.ldif
A jelszót éles helyzetben érdemes titkosítottan megadni a
slappasswd -s nagytitok
parancs használatával.

Szóval van egy fiókunk, aminek egyelőre ugyanúgy elévül a jelszava a nálam érvényben lévő jelszóházirend miatt, mint akárki másnak. Úgyhogy gyorsan dobunk egy olyan házirendet, amelyben a jelszavak örök életűek. Hozzuk létre a ppolicy_no_password_aging.ldif fájlt:
dn: cn=NoPasswordAgingPPolicy,ou=Policies,dc=itthon,dc=cucc
cn: NoPasswordAgingPPolicy
objectClass: pwdPolicy
objectClass: device
objectClass: top
pwdAttribute: userPassword
pwdAllowUserChange: FALSE
pwdLockout: FALSE
Majd adjuk az LDAP-hoz:
ldapadd -D cn=admin,dc=itthon,dc=cucc -w titok -f ppolicy_no_password_aging.ldif
És módósítsuk a pamproxyuser-t: helyezzünk el nála egy pwdPolicySubentry attribútumot, melynek értéke az előző policy dn-je.

Akkor eddig oké. Már csak annyi a dolgunk, hogy az ACL-en módosítunk. Íme az acl.ldif (Azért más a kód formátuma, mint eddig, mert a kiskedvenc tohtml.com lerohadt, helyette van http://w-i-k-i.appspot.com.)
dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn="cn=admin,dc=itthon,dc=cucc" write by * none
olcAccess: {1}to attrs=shadowLastChange,shadowMax by self write by dn="cn=admin,dc=itthon,dc=cucc" write by users read
olcAccess: {2}to dn.base="" by users read
olcAccess: {3}to * by self write by dn="cn=admin,dc=itthon,dc=cucc" write by users read
Azaz a * helyett most már users van, ami magyarul annyit tesz: aki bejelentkezett az olvashatja.
Adjuk hozzá az LDAP-hoz:
sudo ldapmodify -Y EXTERNAL -f acl.ldif
És mennie kell a dolognak.

Akkor most a Samba jön.
Eddig az smb.conf-ban volt egy olyan bejegyzés, hogyaszongya:
ldap admin dn = cn=admin,dc=itthon,dc=cucc
Ő volt az, akinek a jelszavát a Samba számára a sudo smbpasswd -W paranccsal tároltuk. A konfigurációs fájlt módosítjuk:
ldap admin dn = cn=sambaproxyuser,ou=serviceAccounts,dc=itthon,dc=cucc
Ezután felvesszük a sambaproxyuser-t (mint az imént a PAM-os társát) és persze beállítjuk a megfelelő házirendet. És:
sudo service smbd restart

Létrehozzuk a GONsambaAdmins.ldiff fájlt, amely egy groupOfNames osztályú csoportot készít el:
dn: cn=GONsambaAdmins,ou=Groups,dc=itthon,dc=cucc
objectClass: groupOfNames
objectClass: top
cn: GONsambaAdmins
description: Samba Admins
member: cn=placeholder
Azért kell groupOfNames csoport, mert így lehetővé válik egy entitás adott csoporton belüliségének vizsgálata. Ezt még jó rég tanultam meg. A helyőrző meg azért kell, mert groupOfNames nem lehet tag nélkül.
Adjuk hozzá az LDAP-hoz:
ldapadd -D cn=admin,dc=itthon,dc=cucc -w titok -f GONsambaAdmins.ldiff
Ha a csoport kész, akkor tegyük bele tagként a sambaproxyuser-t, majd lássuk ezt az ACL-t (ziesemer.ldiff):
dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by group.exact="cn=GONldapAdmins,ou=Groups,dc=itthon,dc=cucc" write by * break
olcAccess: {1}to dn.one="dc=itthon,dc=cucc" filter=(objectClass=sambaDomain) by group.exact="cn=GONsambaAdmins,ou=Groups,dc=itthon,dc=cucc" write by * break
olcAccess: {2}to attrs=@sambaSamAccount,userPassword by group.exact="cn=GONsambaAdmins,ou=Groups,dc=itthon,dc=cucc" write by * break
olcAccess: {3}to dn.subtree="ou=People,dc=itthon,dc=cucc" attrs=userPassword by self write by * break
olcAccess: {4}to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange by self read by anonymous auth by * none
olcAccess: {5}to * by users read
Érvényesítjük a változtatást:
sudo ldapmodify -Y EXTERNAL -f ziesemer.ldiff
(Tudom, tudom, nincs még GONldapAdmins csoport. Majd lesz.)

Amikor be akarunk lépni Windows-ból, nem fog menni (rossz jelszó... persze). A syslog segít, ha hagyjuk. Először is érdemes az LDAP loggolását úgy módosítani, hogy az ACL-ekkel kapcsolatos dolgokról is beszéljen. Íme a logging.ldiff:
dn: cn=config
changetype: modify
add: olcLogLevel
olcLogLevel: stats acl
A módosító parancs:
sudo ldapmodify -Y EXTERNAL -f logging.ldif
A második dolog, hogy az rsyslog-ban kikapcsoljuk a rate-limitinget. Az /etc/rsyslog.conf fájlba írjuk be, hogy:
$SystemLogRateLimitInterval 0
amit egy
sudo service rsyslog restart
követ.
És itt kellett rájönnöm, hogy mi a helyzet.
Ilyet fogunk látni azok előtt a lekérdezések előtt, amelyek sikertelenek:
ubuserver slapd[1061]: conn=1167 fd=47 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
ubuserver slapd[1061]: conn=1167 op=0 BIND dn="" method=128
Na de ki a tök kapcsolódik üres névvel (dn="") ? A Samba? Először azt gondoltam, hogy talán igen, de az, hogy az ldapi-ról jött a kérés, nyomra vezetett. A szerveren nem állítottam be a PAM proxy user használatát. Miután ezt megtettem, minden szép és jó lett.

Na, akkor Kerberos.
Végig legyen root-shellünk (esetleges elgépelt fileokból eredő segfaultok miatt)
Készítünk GONkerberosAdmins csoportot
Készítünk kerberosproxyuser serviceAccount-ot
Állítsuk be, hogy ne évüljön el a jelszava
Betesszük a csoportba
Eláruljuk a jelszót a Kerberos-nak:
sudo kdb5_ldap_util -D cn=admin,dc=itthon,dc=cucc stashsrvpw -f /etc/krb5kdc/service.keyfile cn=kerberosproxyuser,ou=serviceAccounts,dc=itthon,dc=cucc
Átírjuk az /etc/krb5.conf fájl ldap_kdc_dn és ldap_kadmind_dn bejegyzését.
Megadjuk az új ACL-t:
dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by group.exact="cn=GONldapAdmins,ou=Groups,dc=itthon,dc=cucc" write by * break
olcAccess: {1}to dn.subtree="cn=krbcontainer,dc=itthon,dc=cucc" by group.exact="cn=GONkerberosAdmins,ou=Groups,dc=itthon,dc=cucc" write
olcAccess: {2}to dn.one="dc=itthon,dc=cucc" filter=(objectClass=sambaDomain) by group.exact="cn=GONsambaAdmins,ou=Groups,dc=itthon,dc=cucc" write by * break
olcAccess: {3}to attrs=@sambaSamAccount,userPassword by group.exact="cn=GONsambaAdmins,ou=Groups,dc=itthon,dc=cucc" write by * break
olcAccess: {4}to dn.subtree="ou=People,dc=itthon,dc=cucc" attrs=userPassword by self write by * break
olcAccess: {5}to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange by self read by anonymous auth by * none
olcAccess: {6}to * by users read
Újraindítjuk a szervereket:
sudo service krb5-kdc restart
sudo service krb5-admin-server restart
És kész.
Ital.

Irodalom:
http://blogger.ziesemer.com/2010/12/linux-client-authentication-ldap-pam.html
http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html
http://stackoverflow.com/questions/8121980/openldap-memberof-overlay-configuration-in-ubuntu-11-04
http://simon.kisikew.org/documentation/ldap/sampleacls/
http://www.linuxtopia.org/online_books/network_administration_guides/ldap_administration/slapdconf2_Access_Control.html

27 megjegyzés:

dzson írta...

Egy kis segítséget szeretnék kérni: LDAP-ba nem tudom berakni csak a posix accountok jelszavát. A Sambaban lévőkét a passdb.tdb-ből, vagy smbpasswd fájlból sem sikerült. Van erre megoldás?

raerek írta...

Jól értem, hogy a már meglévő accountok jelszavait akarod áttenni? Ugye itt nem a jelszavak tárolódnak, hanem a hash-ek. Tehát ebben kell tovább gondolkodnod: hash kiíratása tdb-ből, megnézni, hogy az LDAP esetében tutira ugyanaz a hash generálódik és kerül bele a sambaNTpassword (ha jól emléxem) attribútumba, és ha igen, akkor ezt kell szkriptelned az ldap-utils csomag szkriptjeivel.

dzson írta...

Igen, a meglévő szambás jelszavakat a passd.tbd -ből kiraktam smbpasswd-be, így kaptam szöveges fájlt benne az NTLM-es jelszavakkal. Ezek UTF16-os MD4-es hasítások, amelyekből kellene MD5, SHA, vagy CRYPT típusú hasítás. Gondolom ez nem kivitelezhető így inkább az MD4-es azonosító modul kellene a szambához.

raerek írta...

A sambaNTpassword attribútum md4-ben tárol, azaz ha van hash-ed, mindened van.

Bekes Ádám Hemues írta...

Szia !

A "GONldapAdmins" az ugyanolyan csoport, mint a GONsambaAdmins ?

Szerintem azt véletlen kihagytad a leírásból.

Egy kis segítésget szeretnék kérni:
Elvileg azalapján mentem, mint amit leírtál és pamproxy az működik nagyon jól. A sambaproxy-val van gondom. Kipróbáltam, hogy ha a dn-t megváltoztatom az smb.conf-ban a régire, akkor emgy, ha kicserélem az újra, akkor meg nem.

Próbáltam azt is, amit írtál, hogy megemelni a loglevel-t, hogy az acl-ek is látszódjanak, de úgysem kerül semmi sem a log-ba :-(

Pontosítok, csak pamproxyuser, de sehol sem látom, hogy a sambaproxyuser bekerülne a log-ba.
Ötlet, hogy merre induljak esetleg ?

Egyébként nagyon gratulálok az oldalhoz, nagyon hasznos !

raerek írta...

Ööö.
Gyanakodnék, hogy a logba azért nem kerül semmi, mert a samba nem is próbálkozik. Erre utal, hogy a pam felől meg jön a cucc.

Ha jól emléxem (de nem tuti, és zizi az agyam, mert QT-t tanulok programozni:), rég volt), a samba a megadott dn-t tekinti rootnak. smpasswd-vel jelszót változtatni?

(bocs, ha komplett hülyeséget beszélek.)

Bekes Ádám Hemues írta...

Ezt hogy érted ?
Be van állítva a jelszó a sambaproxyusernak, ugyanaz, mint a pamproxyusernak.

Ezzel működik:
ldap admin dn = cn=admin,dc=vayadam,dc=lan
Ezzel a sorral meg nem.
ldap admin dn = dn=sambaproxyuser,ou=serviceAccounts,dc=vayadam,dc=lan

Mindent ugyanúgy csináltam ahogy le van írva. Nem értem miért pamproxy-val próübál menni, amikor a sambaconfigban sambaproxyuser van.

raerek írta...

Ööö. Hülyeséget beszéltem. Mondtam, hogy zizi vagyok.
Goncolom a hozzászólásodban a két dn= a sampaproyuser előtt elírás.Vagy mégsem?

Szóval, ha adminnal mész, akkor látszik a logban, ha sambaproxyuserrel, akkor meg semmi sem?

Bekes Ádám Hemues írta...

Ha az admin-os sor van, akkor sem látok admin bejegyzést, de akkor beenged, míg ha a sambaproxyuser-os sor van, akkor meg nem. Amikor nem enged be, akkor meg pamproxy-val probálkozik.

smb.conf ide vonatkozo része:
passdb backend = ldapsam:ldap://ldap.vayadam.lan
ldap suffix = dc=vayadam,dc=lan
#ldap admin dn = cn=sambaproxyuser,ou=serviceAccounts,dc=vayadam,dc=lan
ldap admin dn = cn=admin,dc=vayadam,dc=lan


raerek írta...

Na de ez az, ami nincs:)

Első körben érd el, hogy ad ldap logban látszódjon bármi. Hajts végre ldapsearch utasításokat.

A másik, meg, hogy nézz szét az /etc/pam.d-ben, hogy miért fallback-el a pamproxyra. Hiszen azt sehol nem adtad meg a sambának... Jól mondom?

Bekes Ádám Hemues írta...

Pontosan :-)
Nem, azt sehol sem mondtam meg neki, hogy hol, hogyan keresse.
/etc/pam.d -ben merre keressek ?
common-auth ?
Ennél részletesebben, hogy acl-eket is mutassa meg, hogy lehetne elérni az ldap-nál ?

raerek írta...

Elviileg a "stats acl" beállítással (ami ebben a postban van) épp azt állítottad be.
Listázd ki a jelenlegi beállításokat, és nézd meg, hogy megette-e. Ha nem megy, úgy emlékszem több posztomban is mutattam olyat, hogy a beállított érték ellenőrzése hogy végezhető, nézz szét.

pam.d-ben a common-auth jó ötletnek tűnik, common-passwd és common-account érdekes még az egész játék alatt, DE minthogy most valami gebasz van, megnézném mindet.

Bekes Ádám Hemues írta...

Szia !

a stats acl gyönyörűen logol, HA ldap browser-al lépek rá, de még akkor is, ha ssh-n megyek be (pamproxy használata), akkor is mutatja, csak azon a fránya samba-nal nem mutatja.

A /etc/pam.d -ben körbenéztem, de semmi hibát nem találok, tuti kinyomja a szemem, mást nem tudok elképzelni :-(

common-account:
account [success=2 new_authtok_reqd=done default=ignore] pam_ldap.so
account [success=1 default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so

common-auth:
auth required pam_group.so use_first_pass
auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_cap.so

common-password:
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass
password requisite pam_deny.so
password required pam_permit.so
password optional pam_gnome_keyring.so

common-session:
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
session required pam_unix.so
session optional pam_ldap.so
session optional pam_ck_connector.so nox11

Egyszerűűűűen nem jövök rá, hogy miért nem logolja sehova sem. :-(

Kérdés: smb.conf ldap admin dn = ... sor

Ő honnan tudja, hogy mi a hozzátartozó jelszo, ahogy az ldap.conf-ban meg volt adva a bindpw, itt honnan tudja ?

3x mentem át a te leírásod alapján, 2x néztem át egy külföldi srácét is, aki ugyanezt csinálta (csak a te leírásod kifejtősebb és jobb), nála is ugyanarra jutottam. Működnie KELLENE.
Bármilyen tipp, ötletet szivesen fogadok és előre is köszi !

Bekes Ádám Hemues írta...

Kész a nyomtatós backend, a cups-os.
Most olvastam (sajnos), hogy a rendszergazdai állásod OFF lett. Ennek ellenére azért küldjem el neked ?
(Saját iromány -->ldap adatbázisból veszi a kvotat es cups alapu a dolog). Te is, meg a leírásaid is segítettek annyit, hogy szívesen adom :-)

raerek írta...

Erre a jelszó dologban írtam pár hozzászólással ezelőtt (csak zizi voltam, és nem lett értelmes, hogy megadtad-e a jelszót.
http://raerek.blogspot.hu/2012/05/samba-tartomanyvezerlo-ubuntu-1204-en_25.html

Itt keresd ki kérlek a sudo smbpasswd -w szót.

És igen érdekel a cups-cucc. Nem tervezed közzétenni?

Bekes Ádám Hemues írta...

Ok, köszi, így már értem. Be is adtam neki ugyanazt a jelszot, amit beállítottam az ldapnál, de így sem működik. A logok alapján most már a sambaproxyuser-el akar menni, de az authentikációig el sem jut, amikor rá akarok browseolni :-S

raerek írta...

Na és ha ldapsearch-öt használsz a sambaproxyuser nevében?

Bekes Ádám Hemues írta...

ldapsearch -x -D cn=sambaproxyuser,ou=serviceAccounts,dc=vayadam,dc=lan -w Nagytitok -h ldap.vayadam.lan -b dc=vayadam,dc=lan

Es hibatlanul adja ki a listat. Ha rossz jelszot adok be, akkor nem.

Nemtudom, hogy hol lehet a gond :-S
Sambaproxy le tudja futtatni az ldapsearch-t. smb.conf-ban is jól van beállítva, ahogy azt már korábban is bemásoltam. Amikor megpróbálok belépni, akkor kér user / pass-t, akkor nem fogadja el.
Valami tipp ...bármi ?! :-))))
Nagyon megköszönném. Jojóó, tudom, igazából ez már csak szépítés az, hogy proxyuserekkel menjen, de adnék kicsit én (is) a biztonságra :-)

Bekes Ádám Hemues írta...

Kicsit pontosítok:
megnéztem részletesen, hogy mit tud az admin és mit nem tud egy adott userról lekérdezni az ldapból a sambaproxyuser.

Amit nem tud:
sambaLMPassword:
sambaNTPassword
sambaPwdMustChange
sambaPwdLastSet

Ez így nem jó, ezért nem enged be.
Elvileg a jogosultságokat a ziesemer.ldiff tartalmazza, neked az tutijó volt ?

dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by group.exact="cn=GONldapAdmins,ou=Groups,dc=vayadam,dc=lan" write by * break
olcAccess: {1}to dn.one="dc=vayadam,dc=lan" filter=(objectClass=sambaDomain) by group.exact="cn=GONsambaAdmins,ou=Groups,dc=vayadam,dc=lan" write by * break
olcAccess: {2}to attrs=@sambaSamAccount,userPassword by group.exact="cn=GONsambaAdmins,ou=Groups,dc=vayadam,dc=lan" write by * break
olcAccess: {3}to dn.subtree="ou=People,dc=vayadam,dc=lan" attrs=userPassword by self write by * break
olcAccess: {4}to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange by self read by anonymous auth by * none
olcAccess: {5}to * by users read

?

Köszi előre is a segítséget.
(LDAP-ot összelőttem már az OPENVPN-el is...kicsit extended módon :-)))
Az érdekelne majd ?

raerek írta...

Na, akkor szépülsz:)
A ziesemer.ldiff elvileg jó, a blogot működő példából írtam, és nem visszamenőleg, hanem párhuzamosan építve a rendszert is. Persze mindig lehet gebasz, egy hibásan ottmaradt buffer a Ctrl-V-hez, vagy bármi:((

A VPN megoldás érdekel, mikor lesz saját blogod? A cups backend meg egy ldap-openvpn már jó kezdet:)

P.

raerek írta...

Na, akkor szépülsz:)
A ziesemer.ldiff elvileg jó, a blogot működő példából írtam, és nem visszamenőleg, hanem párhuzamosan építve a rendszert is. Persze mindig lehet gebasz, egy hibásan ottmaradt buffer a Ctrl-V-hez, vagy bármi:((

A VPN megoldás érdekel, mikor lesz saját blogod? A cups backend meg egy ldap-openvpn már jó kezdet:)

P.

Bekes Ádám Hemues írta...

Nemtudom, lehet indítok sajátot vagy csak simán elküldöm neked.
Ez most már ANNYIRA idegesíííít, hogy semi mással nem biiirok már foglalkozni.

Hogyan lehet rábírni szerinted az (open)LDAP-server-t, hogy a sambaproxyuser olvashatja a sambant meg a sambaLMpassword-ot ?
Mert azokat nem tudja kiolvasni a sambaproxyuser, szerintem az a baja. Próbáltam utánamenni, egyelőre még nem sikerült rávennem.

raerek írta...

Hát úgy, hogy a ziesemer.ldif 3. olcAccess sorában a userPassword után felsorolod ezt a két attribútumot is. Remélem, segít.

Bekes Ádám Hemues írta...

Megpróbálom elejétől kezdeni, hátha akkor működni fog :-)
Köszi a segítséget, még próbálgatom.

Bekes Ádám Hemues írta...

Továbbgondoltam egyébként a preseedinges install-t is meg az egész csomag-kezeléses mizériát, ami utána jön :-)

Saját .deb csomagot gondoltam létrehozni, aminek a depenency-jei azok a programok, amiket installálni szeretnél. Erre írtam egy kis script-et.

Röviden összefoglalva: a preseed csinálja az alapinstall-t, a deb telepitő, a többi programét és a beállításokat pedig....annak szintén lehet .deb-et csinálni.

Arra van valami ötleted, mert azt még nem láttam igazából sehol sem a neten, hogy ha atomic a particionáló, hogy pl. 1db ext4-et szeretnék, de csak mondjuk 10GB-osat, 1 db 1GB-os swap-ot és a maradék maradjon üresen ?
(lvm nélkül, mert az csak bonyolítja a helyzetet)

raerek írta...

Nem, nincs, mindig a legegyszerűbb működő partícionálás volt a cél, többek között azért is, mert ugye elég mély kuss van róla, hogy bonyolultabbat miként készít az ember.

Bekes Ádám Hemues írta...

Sikerült kitúrnom, ha érdekel szólj, vagy mailban vagy akár ide is leírhatom.

Most már BIZTOS vagyok benne, hogy a ziesemer.ldiff-nél van a hiba, mert elötte még megkapja a sambaproxyuser a ntlampassword rovatokat (ldapsearch kiadja), utána meg már nem :-)
anonymous nem tud, sambaproxy igen. Szerintem hagyom is ennyiben, megy működik :-)
Köszi mégegyszer.