AIX vs LDAP sudo

Fórumok

Hello,

AIX-en openldap library-k hasznalataval mukodik az LDAP alapu sudo.

Hozzavalok:
- sudo source (nalam 1.7.4p3)
- openldap, openldap-devel (nalam 2.4.11, bullfreeware.org-rol)
- compiler (nalam xlC 10.1, de termeszetesen gcc is megfelel)

Az openldap libraryket itt ugy hasznaltam, ahogy az rpm-ekbol telepultek, de a vegso formajaban 'nativ' AIX BFF package lesz majd belole, ami tartalmazni fogja az osszes konfigot es libraryt.

Az LDAP szerveren kell a sudoers-t konfiguralni, erre (is) remek peldak vannak a hivatalos oldalon.

1.) openldap install

2.) configure es make

Atmenetileg az alabbi flageket hasznaltam (a vegleges nem ez lesz), de van meg vagy 20-30, tetszes szerint beallithatok, a lenyeg az LDFLAGS es a --with-ldap.

Ha megvan, hogy a csomagban veglegesen hova szeretnenk tenni a librarykat, ezeket kell modositani.


$ LDFLAGS='-blibpath:/opt/freeware/lib:/usr/lib:/lib' ./configure --with-ldap=/opt/freeware --with-ldap-conf-file=/etc/ldap.conf --prefix=/usr/local --without-lecture --with-
logging=both --with-insults --with-classic-insults --without-interfaces

$ make

Ha nem a make installt hasznaljuk, a sudo binarisnak 4111 jog kell.

3.) AIX konfiguracios file-ok

/etc/ldap.conf

Nalam igy nez ki:


host    10.0.0.1
base    c=(c)
sudoers_base ou=(ou),dc=(dc),c=(c)
SUDOERS_DEBUG 1
binddn cn=(cn),o=(o)
bindpw (looong hash)
port 389
scope sub
timelimit 30
bind_timelimit 10
bind_policy     soft
pam_login_attribute cn
pam_lookup_policy       no
pam_password foo
nss_initgroups_ignoreusers      root,ldap
nss_schema      rfc2307bis
nss_base_group          ou=(ou),dc=(dc),c=(c)
nss_base_sudoers        ou=(ou),ou=(ou),o=(o)
nss_map_attribute       uniqueMember member
nss_map_attribute       uid cn
ssl     start_tls
ldap_version    3
pam_filter      objectClass=posixAccount
tls_checkpeer   no

/etc/netsvc.conf

A sudo-ba bele van hegesztve, hogy AIX-en az nsswitch.conf helyett ebben keresgeljen. Ennyi eleg a vegere:


sudoers = ldap, files

Innentol minden, LDAP-bol authentikalt es a 'central' sudoers-ben joggal rendelkezo user tudja hasznalni a sudo-t. Mivel a debug a fenti esetben be van kapcsolva a szerveren, minden sudo muveletre terjedelmes informaciot kapunk, de ebbol mar latszik, hogy mukodik a dolog.

Tovabbi tippek:

- sudo -V tobbek kozott a configure flageket is kiirja
- mivel a sudo nem engedi a LIBPATH hasznalatat, ezert ha a -blibpath opcioval nincs beforditva az openldap library path, userek nem tudjak hasznalni a binarist
- sajnos az AIX/IBM idsldap-pal nem mukodik

Hozzászólások

Könyvjelzőzés.

Kérdés: a third party forrásokat (itt a bullfreeware) mennyire bevett szokás nálatok produktív környezetben használni?
--
2e845cb4c3a5b5bd6508455b1739a8a2

Igazsag szerint erre nincsen hivatalos policy (vagy legalabbis eleg nehezen lenne ertelmezheto). Audit nincs, a 'sandbox' megvan a terjedelmes tesztkornyezet reven, a kritikusnak itelt dolgok eseten sajat buildeket hasznalunk. Amugy fel kezemen meg tudom szamolni, mikre van szukseg (pl bash, bzip2, zlib, wget, rsync, screen).

A linuxtoolbox lenyegeben kalap sz.rt sem er, annyira elavult, ezert egy ideje perzl.org RPM-eket szoktam hasznalni.

Az a baj, hogy ha elmennenk abba az iranyba, hogy sajat build kornyezetet epitsunk, nem lenne elegendo eroforras ennek a karbantartasara. De hosszu tavon persze jo lenne, sokkal jobban megfelelne az igenyeinknek.

A tapasztalat szerint nem szokott (ugyebar 'linuxtoolbox upgrade' sem letezik), nem veletlenul kerulnek teljesen mashova a tenyleges binarisok/libek az rpm-ekbol, /usr alatt csak linkek vannak.

Az eddigi egyetlen 'fuckup' az volt, hogy az AIX altal szallitott gyari rpm.rte az update alatt lekapott valamit, ami a gettext-hez tartozott, ezert azt ujra fel kellett tenni.