AIX LDAP auth

 ( LGee | 2010. november 11., csütörtök - 14:01 )

Itt szandekozom gyujteni nehany hasznos infot ebben a temaban.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

lsldap tool

$ lsldap passwd myname
dn: cn=myname,ou=Department,ou=City,o=Company,c=HU

Userkent futtatva csak ezeket lehet lekerdezni:

$ lsldap -a passwd myname
dn: cn=myname,ou=Department,ou=City,o=Company,c=HU
loginShell: /usr/bin/ksh
homeDirectory: /home/myname
gidNumber: 1111
uidNumber: 2222
objectClass: 
objectClass: 
objectClass: Person
objectClass: Top
objectClass: 
objectClass: posixAccount
objectClass: shadowAccount
objectClass: uamPosixUser
cn: myname

Rootkent joval tobb info:

# lsldap -a passwd myname
dn: cn=myname,ou=Department,ou=City,o=Company,c=HU
auditShell: /usr/bin/crush
OUName1: 
OUType4: 
OUType3: 
OUType2: 
OUType1: 
restrictedShell: /usr/bin/rbash
SecSsp1Rights: 
OU1: 
OU2: 
OU3: 
OU4: 
OUShort1: 
OUShort2: 
OUShort3: 
DirXML-Associations: 
uid: 
givenName: 
fullName: 
Language: 
title: 
sn: 
street: 
...

Tovabb: man lsldap

Ilyen mail, homePhone, mobile, postalAddress, etc. attr-ok se kerhetok le userkent? Vagy csak a testusertol hianyoznak ezek a infok?
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nem, bar lehwt, hogy ez LDAP setup kerdese... gondolom.

szerk. Nem, az lsldap manualjabol:

"When listing the passwd entity with the -a option by root user, lsldap returns all attributes of the found users. However, when the same command is run by a nonprivileged user, lsldap returns only the same commonly readable attributes as returned by the lsuser command in addition to the object class information."

Hat ize. Azert ennel meg a ldapsearch is tobbet tud.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ja, paraméterezd.
--
2e845cb4c3a5b5bd6508455b1739a8a2

alias is my best friend, de amugy meg kerberos, es nem kell auth, csak egy -Y GSSAPI.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Azé ismer pár környezeti változót is, szóval legfeljebb a kezdet kezdetén olyan rohadt kényelmetlen.

Azért egy random gépen egy 'hubazmeg ez kicsoda?' típusú lekérdezés miatt nem fogok ldapsearch-el meg a környezeti változóival szórakozni, ameddig én adminisztrálom az ldap szervereket is :). A kolléga által felvezetett parancs, illetve a slapcat | grep ^dn: jóval gyorsabbak. (humor)
--
2e845cb4c3a5b5bd6508455b1739a8a2

Az lsldap eleg ahhoz, hogy megtudd ki kicsoda.
Az ldap itt is parameterezheto ugye, map file-ok kliens oldalon, a tablak kiterjesztesevel szerver oldalon.
De szerintem ha nem muszaj, nem kell ezt eroltetni.
Az OpenLDAPtol annyiban kulonbozik, hogy DB2 fut alatta es kicsit masok a parancsok.
Kliens oldalon pedig abban, hogy nem az rfc2307-et hasznalja per default. (De meg az is tanithato neki.)
Az SSL kapcsolat szinten, de IBM support javasolt ehhez.
Maga a server tudtommal ingyenes, ha nem kersz supportot, a kliens alapbol az AIX resze.

> Az OpenLDAPtol annyiban kulonbozik, hogy DB2 fut alatta es kicsit masok a parancsok.

A szerver...

De speciel nalunk heterogen kornyezet van, es az LDAP server nem IBM idsldap...
A kliens nem telepul a default installal.

Nem telepul, de telepitheto.

S mi meg implementaltunk SunOne LDAP szerverhez AIX ldap kliens kozti kapcsolatot.

LDAP client daemon vezerlese:

ls-secldapclntd
start-secldapclntd
restart-secldapclntd
stop-secldapclntd
flush-secldapclntd

Erdekes modon nem integraltak az SRC-be.

Nem, mert eredetileg nem volt az AIX, hanem most|mar|meg Tivoli Directory Service resze volt.
Persze a IBM-RND (ReNaming Department) a tivoli es LDAP vonalon igen erosen dolgozik.

Filesetek:

5.3:

ldap.client.adt - Directory Client SDK
ldap.client.rte - Directory Client Runtime (No SSL)

6.1:

idsldap.clt32bit61.rte - Directory Server - 32 bit Client (kell 64 biten is!!)
idsldap.clt64bit61.rte - Directory Server - 64 bit Client
idsldap.cltbase61.adt - Directory Server - Base Client
idsldap.cltbase61.rte - Directory Server - Base Client
(ebben van pl az ldapadd, ldapdelete, ldaptrace stb, meg egy csomo karakterkeszlet)

A felsoroltak kozul egyik sem telepul a default install soran.

Óhh, könyvjelzőzés!
--
2e845cb4c3a5b5bd6508455b1739a8a2

Sziasztok!

a kerdes az lenne, hogy csinalt-e mar valaki AIX alatt ssl-es ldap kapcsolatot? meg lehet oldani egyaltalan plusz fizetos cucc nelkul? a doksik amiket talaltam mind hivatkoznak fizetos progikra...

Epp most kezdtem el foglalkozni vele. Remelhetoleg hamarosan be tudok szamolni valamirol.
Addig is orulnek neki, ha pl dobnal par linket az altalad fellelt doksikra.

Security Guide - LDAP Authentication Load Module
Pl ebben a doksiban a sima IBM-es GSKitrol irnak.

regebben volt az eset, de csak most talaltam meg a threadet, gondoltam feldobom a kerdest hatha mond valaki okossagot. emlekeim szerint nagyjabol minden doksi a tivoli-bol indult ki, ami meg nem a sun one directoryserverre vonatkozott. En fedora directory serverrel probaltam osszeloni, plain auth-tal minden tovabbi nelkul megy, most is ugy mukodik. az ssl-es (tls, gssapi akarmilyen titkositott) kapcsolatot nem birtam mukodesre birni.

Egyelore en sem (AIX 6.1, GSKit v7, Novell eDir):

# mksecldap -c -h ldaphost -a cn=CN,ou=OU,ou=OU,o=O,c=C -p bindpw -d ou=OU,o=O,c=C -n 636 -k /path/to/keystore -w keystorepw
gsksa.rte
gskta.rte
Cannot find users from ou=OU,o=O,c=C base DN.
Client setup failed.

Ami erdekesebb, hogy mikor meg van adva a -k -w, a szerveren a trace szerint mintha el se erne az ldap daemonhoz a kliens (ha -k -w nelkul probalom, de az ssl portot adom meg, akkor viszont igen).

---

szerk. Felraktam a GSKit v8-at, de azzal is ugyanez a helyzet.

SOLVED!

Ime a megoldas:

- idsldap.clt_max_crypto32bit61.rte
- idsldap.clt_max_crypto64bit61.rte

Ezeket kell feltenni az Expansion Packbol, es rogton megy is minden.
ittoolbox.com threadben talaltam meg a megoldast: credits

Az mksecldap hiba nelkul, de a szokottnal joval hosszabb ido alatt fut le. Egyszeru tcpdumppal is latszik, hogy az LDAP kliens hasznalja a 636-os (vagy a megadott egyeb SSL) portot.

Az mksecldap cmdline pedig igy lesz teljes:

mksecldap -c \
-h ldap_host \
-a cn=bind_user,ou=OU,o=O,c=C \
-p bindpw \
-n 636 \
-k /etc/security/ldap/key.kdb \
-w keypw \
-d ou=OU,o=O,c=C \
-A ldap_auth \
-M OS

Azzal szivtam vagy 20 percet, hogy kimaradt az ldap_auth, igy a default unix_authot probalta hasznalni...