Skip to content


Lekcja 18: Active Directory, Exchange, LDAP i AIX

Krok 1:

LDAP może być użyty do autentykowania użytkowników, może dostarczyć informacje zawierającą ich numer telefonu, adres ich biura, może regulować dostęp do folderów NFS, itp.
Tak jak jego poprzednicy, LDAP składa się serwerów LDAP (właściciele informacji) oraz ich klientów. Serwery LDAP organizują informację w strukturach podobnych do odwróconego drzew pozbawionego korzeni (identyczny koncept do folderów systemu). Ta informacja jest klasyfikowana poprzez klasy, atrybuty, schema’ty, itp. Informacja wymagana przez AIX jest przechwywana w Active Directory w folderze “MS Service for UNIX“.
Poprosiłem Administratora Active Directory o potwierdzenie obecności MS Service for UNIX oraz jego gotowości do użycia. Następnie, poprosiłem o stworzenie w AD użytkownika pozbawionego jakichkolwiek przywilejów, który jest upoważnionego wyłącznie do operacji poszukiwawczych. To konto użytkowe umożliwi maszyną AIXu przeszukiwania serwera AD w celu pozytywnego zidentyfikowania próbującego się zalogować użytkownika. Ten użytkownik został nazwany “unixldap”.

Krok 2:

Następnie, załadowałem plik zawierający software IBM Tivoli Director (LDAP) z następującej strony:
http://www- 01.ibm.com/support/docview.wss?rs=767&context=SSVJJU&dc=D400&uid=swg24023291&loc=en_US&cs=utf-8〈=en

I pobrałem z tej strony i rozładowałem potrzebne pliki z archiwum tar w sposób pokazany poniżej:
MarcoPolo:/home/duszyk>tar -xvpf 6.1.0.3-TIV-ITDS-AIX-IF0004.tar
Wynikiem ostatniego polecenia jest dyrektory i zawarte w nim pliki instalacyjne . 6.1.0.3-TIV-ITDS-AIX-IF0004.

Krok 3:

Instalacja wymaganych programów (LDAP klient) zaczyna się tutaj.

# cd 6.1.0.3-TIV-ITDS-AIX-IF0004/images 

Instaluj następujące programy pozwalające na instalację klienta LDAP.

idsldap.clt32bit61.rte       6.1.0.26
idsldap.clt64bit61.rte       6.1.0.26
idsldap.clt_max_crypto32bit61.rte 6.1.0.26
idsldap.clt_max_crypto64bit61.rte 6.1.0.26
idsldap.cltbase61.adt        6.1.0.26
idsldap.cltbase61.rte        6.1.0.26
idsldap.msg61.en_US          6.1.0.26

Nawiasem mówiąc, twój AIX powinien być co najmniej 5.3 TL10 SP3.

Krok 4:

Sprawdź czy zostały zrobione linki z /opt/IBM/ldap/V6.1/bin do /usr/bin.

Na przykład:

# find /usr -name ldapsearch  -ls 

lub

which ldapsearch

Jeżeli linki nie zostały stworzone, to wydaj następujące polecenia:

# cd /opt/IBM/ldap/V6.1/bin;./idslink –I –g –l 32 –f

Jeżeli w dalszym ciągu nie zostały one stworzone, to zmodyfikuj PATH:

export PATH=$PATH:/opt/IBM/ldap/V6.1/bin

Nie zapomnij umieszczenia export w pliku /etc/profile jeżeli chcesz, żeby zmiana PATH była na stałe.

Krok 5:

Administrator ActiveDirectory musi stworzyć konto użytkownicze, które będzie używane przez maszyny AIX do przekazywania serwerowi LDAP pytań, których celem jest autentykacja próbującego się zalogować do maszyny AIX użytkownika. To konto nie powinno mieć żadnych przywilejów z wyjątkiem umiejętności poszukiwania drzewa LDAP na serwerze ActiveDirectory. W moim przypadku ten użytkownik został nazwany unixldap. Pamiętaj, że ten użytkownik “żyje” w środowisku serwera ActiveDirectory, a nie w AIX.

Krok 6:

Unixldap jest moim źródłem informacji reprezentowanej przez ActiveDirectory. Teraz, kolej go zatrudnić. Mówiąc prawdę, mój start nie był pomyślny – polecenie ldapsearch odmówiło posłuszeństwa, ponieważ nie mogło się połączyć z maszyną utrzymującą ActiveDirectory (entwdcdw02 to mój AD serwer). Wydałem polecenie ping entwdcdw02 (nazwa DNS serwera ActiveDirectory), które również odmówiło posłuszeństwa. Wydałem polecenie nslookup entwdcdw02, które również odmówiło posłuszeństwa. Brak odpowiedzi na ostatnie polecenie nasunął mi możliwą przyczynę tej sytuacji – ta maszyna nie może być zlokalizowana w istniejącym środowisku DNS. Zacznijmy od inspekcji pliku /etc/resolv.conf

MarcoPolo:/etc# cat resolv.conf
search infosys.rex.edu rex.edu net.rex.edu
nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx

Co mogę powiedzieć na temat zawartości tego pliku? Nazwa maszyny czy jej adres IP jest określany wyłącznie w jednej z następujących domen: ex.edu, rex.edu, and net.rex.edu używając do tego celu jednego z trzech nameserverów, których adresy IP reprezentują XXX. Mój LDAP serwer nie “żyje” w żadnej z tych domen! Jego domena to rex-dev.edu. Żeby można go było “pingować” wszystko, co należy zrobić to dodać jego domenę!

search infosys.rex.edu rex.edu net.rex.edu,rex-dev.edu

Spróbujmy ponownie “pingować czy nslookup nasz ActiveDirectory serwer. Tym razem wszystko działa jak należy!

Teraz zapytajmy ActiveDirectory serwer o informację.

MarcoPolo:/etc# export LDAP="ldapsearch -h entwdcdw02 -D cn=unixldap,cn=Users,dc=chop-dev,dc=edu -w abc2010! –b”

Powyższe polecenie wydałem w celu zmniejszenia potrzeby “stukania” na klawiatiurze! Poniżej pytam o informację na temat własny (ja).

MarcoPolo:/etc# $LDAP "dc=rex-dev,dc=edu" "(cn=Mark Duszyk)"
CN=Mark Duszyk,OU=INFOSYS,OU=REX Users,OU=Users,OU=Production,DC=rex-dev,DC=edu
objectClass=top
objectClass=person
objectClass=organizationalPerson
objectClass=user
cn=Mark Duszyk
sn=Duszyk
……..
……..

Fakt, że nasz LDAP serwer odpowiada na nasze pytania pozwala nam na wykonanie następnego kroku. Spróbujmy jeszcze raz. Tym razem zapytajmy o wartości kilku moich atrybutów typu “UNIX”.

MarcoPolo:/home/duszyk# $LDAP "ou=rex-dev,dc=edu" "(cn=Mark Duszyk)" gidNumber uidNumber unixHomeDirectory loginShell
CN=Mark Duszyk,OU=INFOSYS,OU=REX users,OU=Users,OU=Production,DC=rex-dev,DC=edu
uidNumber=20008
gidNumber=1
unixHomeDirectory=/home/duszyk
loginShell=/usr/bin/ksh

Krok 7:

Nadszedł czas, żeby zrobić z mojej AIX maszyny klienta serwera LDAP – moja maszyna AIX ma połączenie z serwerem LDAP, który odpowiada na wszystkie jej pytania. Do tego celu należy wydać polecenie mksecldap.

mksecldap -c -h entwdcdw02 -a cn=unixldap,cn=users,dc=rex-dev,dc=edu -p abc2010! -d cn=users,dc=rex-dev,dc=edu

entwdcdw02 powyżej to imię mojego serwera Active Directory. W przypadku sukcesu, polecenie mksecldap zmodyfikuje pliki /etc/inittab oraz /etc/secrity/ldap/ldap.cfg. Również zastartuje ono demona /usr/sbin/secldapclntd.

MarcoPolo:/etc# ps -ef | grep ldap
root 254114      1   0 13:55:24      -  0:00 /usr/sbin/secldapclntd
MarcoPolo:/etc#

Sprawdźmy plik /etc/inittab

MarcoPolo:/etc# grep ldap /etc/inittab
ldapclntd:23456789:wait:/usr/sbin/start-secldapclntd  
MarcoPolo:/etc# 

Krok 8:

Czas na modyfikację pliku /etc/security/ldap/ldap.cfg. Pierwszy krok to podanie nazwy mojego servera LDAP (ActiveDirectory).
# Comma separated list of ldap servers this client talks to
ldapservers:entwdcdw02

Teraz podaję definicję (“cn”) mojego specjalnego użytkownika:
# LDAP server bind distinguished name (DN)
binddn:cn=unixldap,cn=users,dc=rex-dev,dc=edu

Użytkownik, mógłby być upoważniony do zalogowania przez maszynę AIX, do której on się loguje, ale to by zaprzeczyło użyciu LDAP. Ja wybrałem autentykacje przez LDAP serwer.

# Authentication type. Valid values are unix_auth and ldap_auth.
# Default is unix_auth.
# unix_auth - Retrieve user password and authenticate user locally.
# ldap_auth - Bind to LDAP server to authenticate user remotely through LDAP.
authtype:ldap_auth

Moje ostatnie modyfikacje określają miejsce od którego należy zacząć poszukiwania na pytania klienta (maszyna AIX) :

# Base DN where the user and group data are stored in the LDAP server.
# e.g., if user foo's DN is: uid=foo,ou=people,cn=aixdata
# then the user base DN is: ou=people,cn=aixdata
userbasedn:DC=rex-dev,DC=edu
groupbasedn:DC=rex-dev,DC=edu

Pozostałe elementy /etc/security/ldap/ldap.cfg nie zostały zmienione.

Teraz należy odświeżyć demona LDAP na tej AIX maszynie. To może być zrobione wydając pierw polecenie /usr/sbin/stop-secldapclntd po czym zaś /usr/sbin/start-secldapclntd lub /usr/sbin/restart-secldapclntd.

Krok 9:

Muszę podjąć decyzję w jaki sposób kontrolować do których maszyną należą użytkownicy. Po co? Jeżeli użytkownicy są autoryzowani przez Active Directory, to jak długo użytkownik poda poprawny login i hasło (password) to LDAP pozwoli mu na zalogowanie. W moim przypadku ja chcę, żeby Administratorzy Oracle mogli się logować wyłącznie do maszyn z tą aplikacją. To samo odnosi się do użytkowników Lawson czy innych aplikacji. To prezentuje ciekawe pytanie. Jak rozwiązać przypadek maszyny posiadającej bazę danych Oracle i aplikację LAWSON?
Ostatnie pytanie (jak ograniczyć dostęp użytkowników do maszyn) można odpowiedzieć na co najmniej pięć sposobów. Najprostszym sposobem jest kilka linijek kodu w pliku /etc/profile. To samo można także osiągnąć przy użyciu netgroups czy filtrów LDAP. Mówiąc o filtrach LDAP ja mam na myśli stosowanie filtrów z poleceniem ldapsearch
Skoro nasz 2008 AD serwer współpracuje z serwerem Exchange 2007 my mamy dostęp do piętnastu extensionAttributes (extensionAttribute1 do extensionAttribute15). Każdy z tych atrybutów może być użyty do przechowania dodatkowej informacji o użytkowniku w środowisku LDAP. Administrator AD pozwolił mi na użycie extensionAttributes14. Ten atrybut będzie przechowywał kategorię użytkownika co pozwoli mi na kontrolę maszyn (AIX) do, których ten użytkownik będzie miał dostęp.

Jak to jest zrobione? W zależności od roli pełnionej przez użytkownika, ten atrybut będzie posiadał jedną z takich wartości: – jeżeli jest on użytkownikiem aplikacji LAWSON – LawAdm, jeżeli jest on Administratorem tej aplikacji – LawAdm, jeżeli jest on administratorem Oracle – OraDba, jeżeli jest on administratorem aplikacji Clarity – Dlr-Adm, itp…..

Następne polecenie pokazuje jak znaleźć wartość tego atrybutu w przypadku użytkownia znanego jako Mark Duszyk w LDAP domenie zwanej rex-dev.edu

nimprdp1:/home/duszyk# $LDAP "dc=rex-dev,dc=edu" "(cn=Mark Duszyk) extensionAttribute14

Jego produkcja to:

extensionAttribute14=AixAdm

Jak LDAP klient na danej maszynie AIXu decyduje czy umożliwić lub nie logującemu użytkownikowi dostęp do tej maszyny? To strona autentykacji jest kontrolowana przez /usr/sbin/secldapclntd, który odtrzymał tę wiedzę z jednej zdania w pliku /etc/security/ldap/ldap.cfg. To zdanie zaczyna się następującym wyrazem: userbasedn:. W przypadku maszyny posiadającej Oracle oraz Lawson może ona wyglądać następująco:

userbasedn:DC=rex-dev,DC=edu??(|(extensionAttribute14=LawUsr) (extensionAttribute14=LawAdm)(extensionAttribute14=OraDba))

W powyższym zdaniu, charakter “| oznacza logiczne “lub” (OR) – użytkownik, którego extensionAttribute14 posiada wartość LawAdm lub OraDba lub LawUser będzie miał dostęp do maszyny po podaniu poprawnego hasła. Pamiętaj, że zmiana zawartości pliku ldap.cfg wymaga odświeżenia secldapclntd (lub stop-secldapclntd /start-secldapclntd). W tym momencie zadajmy sobie następujące pytanie – czy musimy używać któryś z tych extensionAttributes? Na przykład, co stoi na przeszkodzie wykorzystania do tego samego celu gidNumber? Nic, nic nie stoi na przeszkodzie wykorzystania do tego celu innych atrybutów. Chwilę temu, zmieniłem ldap.cfg, który teraz wygląda następująco: userbasedn:DC=rex-dev,DC=edu??(gidNumber=1).Po odświeżeniu secldapclntd i sprawdzeniu, wszystko działa tak ja powinno – tylko członkowie należący do odpowiednie grupy/grup mają dostęp do tej maszyny.

Nawiasem mówiąc, pytania o informację przechowywaną przez serwera LDAP mogą zawierać inne logiczne “kwalifikatory” takie jak ! (NOT/NIE), & (AND/RÓWNIEŻ), * (jakakolwiek wartość), = (równający się z). Pamiętaj również, że LDAP nie zwraca uwagi na duże/małe litery.

Krok 10:

Ja uważam, że wszystkie administracyjne konta (aix/aplikacja) powinny być zarządzane lokalnie – na poziomie danej maszyny. Konta pozostałych użytkowników powinny być kontrolowane i zarządzane przez LDAP. Ten podział ma miejsce w pliku code>/etc/security/user. Zmieniam zwrotkę default: żeby

SYSTEM = "LDAP"
registry = LDAP

Dla administratorów AIXu i aplikacji, zmieniam w zwrotce każdego z nich:

auth1 = SYSTEM
auth2 = NONE

W przypadku ActiveDirectory, długość nazwy konta (login name) może być dłuższa niż 8 charakterów. Aby pozwolić na dłuższe (do 124 charakterów) login należy wydać następujące poleceni:

chdev –l sys0 –a max_loginname=125

Po pomyślnej weryfikacji login i hasła, użytkownik ląduje w miejscu powszechnie znanym jako katalog własny. To miejsce jest określone atrybutem unixHomeDirectory, który musi być podany definiując użytkownika w ActiveDirectory. Umiejętności tworzenia katalogów własnych w chwili logowania bardzo upraszcza administrację użytkownikami. To może być rozwiązane różnymi metodami. Jedna z tych metod jest pokazana poniżej. Należy umieści ten kod w /etc/profile

export HOME=/home
if [[ ! -d $1 ]]
then
      mkdir -p $HOME/$USER
      cd $HOME
      chown $USER:`lsuser $USER | awk '{print $3}' |\
                                 awk -F = '{print $2}'` $USER
fi

Przydatne polecenia:

Status procesu secldapclntd:

MarcoPolo:/etc# ls-secldapclntd
ldapservers=entwdcdw02
ldapport=389
active connections=1
ldapversion=3
userbasedn=DC=rex-dev,DC=edu
groupbasedn=DC=rex-dev,DC=edu
idbasedn=
usercachesize=1000
……

Detale użytkownika LDAPu (polecenie łatwe do zapamiętania)

nimprdp1:/etc/security# lsldap -a passwd duszyk
……………………
……………………

Znajdz wszystkich mających “extensionAttribute14=nimprdp1,nimprds1,MarcoPolo”

$LDAP "dc=rex-dev,dc=edu""(extensionAttribute14=nimprdp1,nimprds1,MarcoPolo)"

Pokaż każdego “extensionAttributes

$LDAP "dc=rex-dev,dc=edu" -s sub objectclass=* | grep -i attrib

Znajdź wartości moich atrbut ów w Active Directory:

$LDAP "dc=rex-dev,dc=edu" "(cn=Mark Duszyk)" gidNumber uidNumber unixHomeDirec tory loginShell
CN=Mark Duszyk,OU=INFOSYS,OU=rex Users,OU=Users,OU=Production,DC=rex-dev,DC=edu
uidNumber=20008
gidNumber=1
unixHomeDirectory=/home/duszyk
loginShell=/usr/bin/ksh

Odśwież ldap na AIX maszynie:

restart-secldapclntd

Stop ldap na AIX maszynie:

 stop-secldapclntd

Start ldap na AIX maszynie:

start-secldapclntd

Dobra literatura na temat LDAPu i AIXu:
LDAP for Rocket Scientists: http://www.zytrax.com/books/ldap/
ldapsearch explained: https://www.opends.org/wiki/page/Ldapsearch
AIX 5L LDAP User Management: http://www.ibm.com/developerworks/aix/library/au-aixadsupport.html


12 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Jeff says

    great document, one question..

    have you verified whether or not AIX security policies are being adhered to? when we first implemented LDAP authentication against a non Tivoli LDAP server(SunONE) we discovered multiple issues relating to password aging/expiration enforcement that resulted in several ifix’s from IBM.. i haven’t been keeping track of which SP’s they’ve been rolled into but definitely something to verify and if not, seek out the latest updates.

  2. MarkD:-) says

    Jeff,

    as far as I am aware, as soon as LDAP (ActiveDirectory) does user authentication all password attribs like length, character combination, number of failed logins, etc – all these are under AD control. One has to look at AD (or any other “foregin” LDAP server used) side for values of these attributes to verify if they match (or not) what used to be in force before LDAP. Look into the chosen AIX/AD map file (in /etc/security/ldap) to see what attributes are implemented/translated or which is mandatory/optional from AIX into AD.
    By the way do you know how to AutoFS a CIFS? I need to know if this is possible with AIX.

    Thanks for your comment,

    MarkD:-)

  3. Wendy says

    Dear Mark,

    Another question about step 10:
    if I want to use the filter with gidNumber
    whenever I change this attribute (gidNumber) in AD (LDAP server) for a certain user,
    I found I need to restart-secldapclntd to make it effective.

    Is there any alternative that I don’t need to restart-secldapclntd for refresh the data and every change in AD server can reflect immediately during AIX user login.

    p.s. I need to control LDAP users to login certain AIX servers and the control is on the hand of AD administrator.

    Thanks a lot.

  4. MarkD:-) says

    Wendy,
    I am not aware of any alternative in this case. I use TDS (Tivoli Directory Server ver.6.3) LDAP with the pass-through authentication against AD (my AIX users have AD logins/passwords) – all user info except his/her password is stored in TDS. In this case all attribute changes to LDAP object (user) are immediately passed to and visible by any AIX client.
    It may sound silly, but what about a cron job to re-fresh secldapclntd every so often?

    All the best,

    MarkD 🙂

  5. Wendy says

    oh….thank you!

    But I found out that for a certain user, he/she will be in several groups.
    So I create a group in AD and there’re a number of users for it. (many-to-many relationship)
    I try to use groupbasedn to filter that specific group …for a certain server (I thought it acts like other attribute)
    but seems no connection between group and user can be defined.

    Sorry that it seems a question of AD (but of course I define the user and group with Unix attribute)

    Is there any steps missing for this type of set up?

    Hope I can find a way out !

    Thank you for your patience.

  6. MarkD:-) says

    Wendy,

    I just had to modify one user group membership. I changed it on the TDS server but the change was not propagated to the client (host) till I recycled the secldapclntd….

    Have a good weekend.

    Mark

  7. Wendy says

    My colleague found out that when they change password via the LDAP server.
    Both the old and new password are valid in AIX.
    And I found that the old password would be invalid after around 1 hour.

    Is there any cache or any parameter to set to shorten this delay and confusion ?

    Thanks in advance.

  8. MarkD:-) says

    Wendy,

    this is new to me – our AIX users cannot change their password from AIX host. Passwords are stored in ActiveDirectory and TDS (LDAP) server has not “tools” to request a password change on a user behalf.
    Our TDS servers just match AIX login versus AD sAMAccountName and it the match is positive AD sends the password to TDS (LDAP servers) which compares it to what user entered. If user/AD passwords are the same user is granted access to AIX host.

    Maybe you should contact IBM/LDAP support – the presence of two passwords is not right and it could be dangerous.

    Thanks,

    MarkD

  9. Wendy says

    Thanks a lot. Mark.
    Seems my problem is due to the following issue:
    “Microsoft Windows Server 2003 Service Pack 1 (SP1) modifies NTLM network authent…Microsoft Windows Server 2003 Service Pack 1 (SP1) modifies NTLM network authentication behavior. After you install Windows Server 2003 SP1, domain users can use their old password to access the network for one hour after the password is changed. Existing components that are designed to use Kerberos for authentication are not affected by this change.”

    Ref : http://support.microsoft.com/?id=906305

  10. tansha says

    Hi Mark,

    I would first like to thank you for your great post on the subject. It really sheds much like on the topic and very useful as a reference guide.

    I would appreciate if you could please provide me some guidance as to one particular requirement. In fact, we need is to provide access to a share on an AIX 7.1 box to a group of users defined in AD. The samba share is currently working but is accessible to all. We would like to integrate authentication to access the share with Active Directory using LDAP.

    After read your s post, I am considering to implement the approach is your document. However, I am concerned that if I do LDAP client authentication on the AIX box, not only will those users get access to the share but in addition will also be able to log into the box as they would already have been authenticated by AD.

    Am I right and is there any suggestion you can provide to achieve the desired purpose while at the same time restricting access to login to the box?

    I also need to ensure that aix users locally defined on the box should continue to login by using the local password authentication method and not via AD.

    As mentioned above, in fact, we need is to provide access to a share on an AIX 7.1 box to a group of users defined in AD.

    We have samba 3.6 and have the pware61-64.openldap.rte (OpenLDAP 2.4.23 64 bit) version installed.

    I would really appreciate you feedback.

    Thanks and warm regards,

  11. MarkD:-) says

    Tansh,

    I actually have never used Samba…..
    If you use LDAP to authenticate (regardless the location of the authority – LDAP or AD server) you are fully able to control access to a host using LDAP “filters”.
    To allow local accounts to still be administered “locally” you have to modify their definition stanzas (in /etc/security/user) to contain the following two entries:

    SYSTEM = “compat”
    registry = files

    But the “default” section of the same files must contain instead:

    SYSTEM = “LDAP”
    registry = LDAP

    or if you use AD Kerberos:

    SYSTEM = “KRB5LDAP”
    registry = KRB5LDAP

    Just remember to populate users UNIX attributes of AD (id. pgrp, groups, shell, home, etc….) and you are correct every user with UNIX attribs in LDAP or AD will be able to login to every UNIX host with this services present. But there are LDAP filters that provide an extremely flexible way to control user access.

    Thanks and good luck,

    MarkD:-)

  12. Tansha says

    Hi Mark,

    Thanks for the tips and advise. I will refer to your documented procedure and taken note of your suggestion and try to work it out.

    Thanks again.



Some HTML is OK

or, reply to this post via trackback.

WordPress Anti Spam by WP-SpamShield



Copyright © 2016 - 2017 Waldemar Mark Duszyk. All Rights Reserved. Created by Blog Copyright.