389 е високопроизводителен LDAP директориен сървър, който поддържа виртуални LDAP сървъри (инстанции), репликация, автоматизирано създаване на резевни копия, промяна на повечето конфигурационни опции без да се налага да се рестартира сървъра. Документацията по-долу показва как да бъде инсталиран и настроен този сървър за нуждите на HPC инфраструктурата. В LDAP директорията, която той поддържа, се съхраняват записите за потребителите.

Преди да започнете инсталирането на пакетите със софтуера за изграждане на 389 директориен сървър, убедете се, че имате инсталиран хранилищния пакет за използване на EPEL (за да направите тази проверка не е нужно да сте super user):

$ rpm -q epel-release

Ако хранилищният пакет е инсталиран, ще видите името му и версията:

epel-release-7-11.noarch

Ако не получите нищо като резултат, то пакета не е инсталиран в системата и неговото инсталиране трябва да стане така (с права на super user):

# yum install epel-release

В допълнение, изпълнете:

# yum-config-manager --disable epel

Накрая, инсталирайте нужните пакети:

# yum --enablerepo=epel install 389-ds-base 389-ds-console 389-adminutil 389-admin-console 389-admin openldap-clients

По подразбиране се инсталира само една инстанция. Нужно е да се отбележи, че инстанцията е базирана на локален IP адрес и име на хост. Това означава, че ако желаете да имате две инстанции на 389 обслужвани на един физически сървър, трябва да конфигурирате два IP адреса върху локален за сървъра мрежови интерфейс и за всеки от тези адреси да имате съответните "A", "AAAA" и "PTR" записи в DNS.

Преди да започнете със създаването на 389 инстанция, трябва да направите една важна системна настройка, свързана с ресурсите, които 389 сървъра ще използва. За да опишете настройката, отворете с текстов редактор файла /etc/security/limits.conf (изискват се права на super user) и в края му добавете реда:

*        -        nofile        8192

Рестартирайте системата, за да могат новите настройки да влязат в сила при зареждането ѝ.

За да започнете със създаването на инстанция, изпълнете като super user следния скрипт (той е част от пакета 389-ds-base):

# setup-ds.pl

Той ще стартира диалогово меню, в което ще трябва да въвеждате параметрите на инстанцията (следвайте инструкциите изписани в червено по-долу):

==============================================================================
This program will set up the 389 Directory Server.

It is recommended that you have "root" privilege to set up the software.
Tips for using this  program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" or the word "back" then "Enter" to go back to the previous screen
  - Type "Control-C" to cancel the setup program

Would you like to continue with set up? [yes]: # не въвеждайте нищо, натиснете "Enter"

==============================================================================
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

389 Directory Server system tuning analysis version 14-JULY-2016.

NOTICE : System is x86_64-unknown-linux3.10.0-957.10.1.el7.x86_64 (1 processor).

Would you like to continue? [yes]: # не въвеждайте нищо, натиснете "Enter"

==============================================================================
Choose a setup type:

   1. Express
       Allows you to quickly set up the servers using the most
       common options and pre-defined defaults. Useful for quick
       evaluation of the products.

   2. Typical
       Allows you to specify common defaults and options.

   3. Custom
       Allows you to specify more advanced options. This is 
       recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]: # не въвеждайте нищо, натиснете "Enter"


==============================================================================
Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
<hostname>.<domainname>
Example: eros.example.com.

To accept the default shown in brackets, press the Enter key.

Warning: This step may take a few minutes if your DNS servers
can not be reached or if DNS is not configured correctly.  If
you would rather not wait, hit Ctrl-C and run this program again
with the following command line option to specify the hostname:

    General.FullMachineName=your.hostname.domain.name

Computer name [hpc-service-host.unite.uni-sofia.bg]: # не въвеждайте нищо, натиснете "Enter"

==============================================================================
The server must run as a specific user in a specific group.
It is strongly recommended that this user should have no privileges
on the computer (i.e. a non-root user).  The setup procedure
will give this user/group some permissions in specific paths/files
to perform server-specific operations.

If you have not yet created a user and group for the server,
create this user and group using your native operating
system utilities.

System User [dirsrv]: # не въвеждайте нищо, натиснете "Enter"
System Group [dirsrv]: # не въвеждайте нищо, натиснете "Enter"

==============================================================================
The standard directory server network port number is 389.  However, if
you are not logged as the superuser, or port 389 is in use, the
default value will be a random unused port number greater than 1024.
If you want to use port 389, make sure that you are logged in as the
superuser, that port 389 is not in use.

Directory server network port [389]: # не въвеждайте нищо, натиснете "Enter"

==============================================================================
Each instance of a directory server requires a unique identifier.
This identifier is used to name the various
instance specific files and directories in the file system,
as well as for other uses as a server instance identifier.

Directory server identifier [hpc-service-host]: # не въвеждайте нищо, натиснете "Enter"

==============================================================================
The suffix is the root of your directory tree.  The suffix must be a valid DN.
It is recommended that you use the dc=domaincomponent suffix convention.
For example, if your domain is example.com,
you should use dc=example,dc=com for your suffix.
Setup will create this initial suffix for you,
but you may have more than one suffix.
Use the directory server utilities to create additional suffixes.

Suffix [dc=unite, dc=uni-sofia, dc=bg]: o=unite-bg.eu въведете името на върха на дървото (за примера е o=unite-bg.eu)

==============================================================================
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and typically has a
bind Distinguished Name (DN) of cn=Directory Manager.
You will also be prompted for the password for this user.  The password must
be at least 8 characters long, and contain no spaces.
Press Control-B or type the word "back", then Enter to back up and start over.

Directory Manager DN [cn=Directory Manager]: # не въвеждайте нищо, натиснете "Enter"

==============================================================================
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and typically has a
bind Distinguished Name (DN) of cn=Directory Manager.
You will also be prompted for the password for this user.  The password must
be at least 8 characters long, and contain no spaces.
Press Control-B or type the word "back", then Enter to back up and start over.

Directory Manager DN [cn=Directory Manager]: 
Password: # въведете паролата за администратора на инстанцията
Password (confirm): # въведете паролата още веднъж
Your new DS instance 'hpc-service-host' was successfully created.
Exiting . . .
Log file is '/tmp/setupeCaI9P.log'

ВНИМАНИЕ! Ако не виждате съобщението "Your new DS instance 'hpc-service-host' was successfully created." (във вашия случай може името на инстанцията да не е hpc-service-host) в края на диалога, то инстанцията не е създадена успешно и трябва да проверите каква е причината за това, анализирайки записите във файла, чието име и път са посочени след Log file (последния ред в изхода, показан по-горе).

В случай, че инстанцията е създадена успешно, трябва да я направите зареждаема по времето, по което се зарежда системата:

# systemctl enable dirsrv@hpc-service-host

ВНИМАНИЕ! След "@" в този команден ред стои името на инстанацията, която автоматично се определя на база на името на хоста (вижте това в диалога по конфигурирането, даден по-горе, при указването на стойност след "Directory server identifier"), освен ако не го зададете ръчно. Отбележете, че името на инстанцията е това, което е включено в името на директорията /etc/dirsrv/slapd-hpc-service-host - името на инстанцията стои там след slapd-. При вас това име на инстанция може да бъде различно!

След това рестартирайте услугата, за да проверите, че се зарежда нормално (не бива да виждате никакви съобщения, изведени след изпълнение на командния ред по-долу):

# systemctl restart dirsrv@hpc-service-host

За да сте напълно сигурни, че инстанцията наистина работи, проверете и статуса на изпълнение на процесите на демона на 389 (това е изпълнимия файл /sbin/ns-slapd). Ако демонът на инстанцията работи нормално, след изпълнението на

# systemctl status dirsrv@hpc-service-host

ще виждате текста маркиран по-долу в зелено:

● dirsrv@hpc-service-host.service - 389 Directory Server hpc-service-host.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2019-04-10 08:12:16 EEST; 19h ago
 Main PID: 14690 (ns-slapd)
   Status: "slapd started: Ready to process requests"
   CGroup: /system.slice/system-dirsrv.slice/dirsrv@hpc-service-host.service
           └─14690 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-hpc-service-host -i /var/run/dirsrv/slapd-hpc-service-host.pid

Ако вместо това виждате съобщения оцветени в червено, то най-вероятно има проблем при стартирането на инстанцията. За да откриете причината, проверете съдържанието на файла /var/log/dirsrv/slapd-hpc-service-host/errors (отчитайки, че вашата инстанция ще е с име различно от hpc-service-host и следователно трябва да въведете правилното име на директория).

Следващата стъпка е конфигуриране на възможността за осъществяване на SSL комуникация от и до инстанцията на 389. Най-важното, което трябва да знаете преди да започнете с SSL конфигурацията е, че 389 директорийния сървър не използва OpenSSL библиотеките (за разлика от повечето SSL приложения в CentOS 7 и Scientific Linux 7). Вместо това, той е компилиран спрямо NSS библиотеките. Поради това, инсталирането на ключове и X.509 сертификати се извършва по специфичния за NSS начин.

Това, което трябва да имате на разположене, преди да започнете конфигурацията, е PKCS#12 файла, в който се намира частния ключ, X.509 сертификата, свързан с този ключ и сертификатната му верига. За примера по-долу предполагаме, че PKCS#12 файла е /tmp/hpc-service-host.unite.uni-sofia.bg.p12. Влезте в директория /etc/dirsrv/slapd-hpc-service-host като super user (заменете hpc-service-host с конкретното име на вашата инстанция). Файловете на NSS хранилището са в тази директория по подразбиране (те ще са празни, ако в тях не сте поставяли нищо преди това). Те ще са с имена cert8.db, key3.db и secmod.db. В същата тази директория изпълнете:

# certutil -L -d .

за да проверите дали в хранилището няма вече инсталирани сертификати. При прясна инсталация на инстанция, в хранилището няма да има нищо и ще видите следото съобщение изведено на екрана:

Database needs user init

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Първата стъпка, преди прехвърлянето на ключа и сертификатите от PKCS#12 файла от PKCS#12 файла в това празно хранилище, е да го защитите с парола. Това става така (изпълнено в директорията на инстанцията, упомената по-горе):

# certutil -W -d .

Ще трябва да въведете паролата двукратно (при въвеждането на паролата няма да бъдат извеждани никакви символи):

Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

Enter new password: 
Re-enter password:

След като направитe това, трябва да създадете файла pin.txt (в същата директория, в която се намират и файловете cert8.db, key3.db и secmod.db) и да установите съответните права върху него:

# touch pin.txt && chmod 600 pin.txt && chown dirsrv:dirsrv pin.txt

Отворете така създадения pin.txt с текстов редактор и поставете в него на един ред (!!!) следения текст (заменяйки текста password по-долу с паролата, която сте задали за защита на NSS хранилището по-горе):

Internal (Software) Token:password

След като запазите промените в pin.txt, може да започнете с прехвърлянето на съдържанието от PKCS#12 файла в NSS сертификатното хранилище на 389 така:

# pk12util -i /tmp/hpc-service-host.unite.uni-sofia.bg.p12 -d /etc/dirsrv/slapd-hpc-service-host

В хода на прехвърлянето ще трябва първо да въведете паролата за защита на хранилището (тази, която е зададена по начина обяснен по-горе):

Enter Password or Pin for "NSS Certificate DB":

и само след успешното ѝ въвеждане, ще бъде поискатна тази парола, която е използвана за да бъдат защитени ключовете в PKCS#12 файла:

Enter password for PKCS12 file:

Ако и тази парола бъде въведена, съдържанието ще бъде прехвърлено в хранилището и ще видите следното съобщение за успешен край на операцията:

pk12util: PKCS12 IMPORT SUCCESSFUL

За да проверите, дали съдържанието е успешно прехвърлено, изведете списъка с инсталирани в хранилището сертификати:

# certutil -L -d /etc/dirsrv/slapd-hpc-service-host

Ще бъде изведена информация подобна на следната:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

UNITe ECC CA - uni-sofia.bg                                  ,,   
hpc-service-host.unite.uni-sofia.bg#2019                     u,u,u
SU ECC Root CA - uni-sofia.bg                                ,,

Сървърският сертификат, който ще бъде използван за 389 инстанцията, ще има срещу името си записа "u,u,u". Този запис означава, че сертификата се намира в хранилището заедно с частния си ключ. Допълнително, ще виждате е списъка и сертификатите от веригата на сървърския сертификат. За примера горе това са сертификатите с имена "UNITe ECC CA - uni-sofia.bg" и "SU ECC Root CA - uni-sofia.bg". Трябва да знаете предварително кой сертификат е върха на веригата и да го маркирате като такъв, поставяйки за него в сертификатното хранилище флаговете "CT,C,C", както е показано по-долу (след -n се въвежа името на сертификата, с което той е известен в хранилището):

# certutil -M -n "SU ECC Root CA - uni-sofia.bg" -t CT,C,C -d /etc/dirsrv/slapd-hpc-service-host

Ако изпълните след това пак:

# certutil -L -d /etc/dirsrv/slapd-hpc-service-host

ще видите списък с инсталираните и маркирани сертификати:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

UNITe ECC CA - uni-sofia.bg                                  ,,   
hpc-service-host.unite.uni-sofia.bg#2019                     u,u,u
SU ECC Root CA - uni-sofia.bg                                CT,C,C

Отбележете, че не е нужно да поставяте флагове на междинните сертификати (такъв в случая е "UNITe ECC CA - uni-sofia.bg").

След като сертификатите са инсталирани в сертификатното хранилище на инстанцията, по начина показан по-горе, може да пристъпите към конкректните настройки на сървъра, за поддръжка на SSL комуникация с клиентите (или с други LDAP сървъри). Преди да започнете конфигурирането, е добре да запазите текущата стартова конфигурация на сървъра за тази инстанция, БЕЗ ДА СПИРАТЕ ИНСТАНЦИЯТА. Копието е нужно за да възстановите последната работеща стартова конфигурация, ако допуснете грешка при съставянето на новата (в която ще бъде описано използването на SSL). Стартовата конфигурация се намира във файла /etc/dirsrv/slapd-hpc-service-host/dse.ldif (ако името на вашата инстанция е hpc-service-host, ако не - променете името на директорията). Създаването на копие на нейно копие може да направите така (като super user):

# cp /etc/dirsrv/slapd-hpc-service-host/dse.ldif /etc/dirsrv/slapd-hpc-service-host/dse.ldif.bak

След това, в системата, в която работи инстанцията на 389, създадена по рецептата по-горе, изтеглете локално в /tmp следния файл:

enable_ssl.ldif

Отворете го с текстов редактор и в него променете единствено името на инстанцията, което се намира в записите след nsKeyfile и nsCertfile. Промяната има за цел да замени името на инстанция hpc-service-host с името, което има вашата:

...
add:nsKeyfile
nsKeyfile: alias/slapd-hpc-service-host-key3.db # тук заменете hpc-service-host
-
add:nsCertfile
nsCertfile: alias/slapd-hpc-service-host-cert8.db # тук заменете hpc-service-host
...

ВНИМАНИЕ! Не изтривайте съществуващи и не създавайте нови редове във файла! В противен случай той няма да бъде използваем!

Запазете промените и изпълнете (в системата, в която работи инстанцията) следния команден ред:

$ ldapmodify -D "cn=Directory Manager" -x -W -f enable_ssl.ldif

Ще трябва да въведете паролата за cn=Directory Manager, която сте задали при създаването на инстанцията (или сте променяли след това). Ако не получите съобщение за грешка, то съдържанието на ldif файла, който сте изтеглили, ще бъде прехвърлено в стартовата конфигурация на 389.

Ако бъде изведено съобщение за грешка, трябва да спрате инстанцията, да възстановите конфигурацията от резервното копие и отново да стартирате инстанцията (заменете името на инстанция hpc-service-host в примера с актуалната във вашия случай):

# systemctl stop dirsrv@hpc-service-host
# cp /etc/dirsrv/slapd-hpc-service-host/dse.ldif.bak /etc/dirsrv/slapd-hpc-service-host/dse.ldif
# systemctl start dirsrv@hpc-service-host

и да анализирате къде е възниканала грешка.

В случай, че промените в конфигурацията, засягащи SSL, са усшено въведени, може да пристъпите към проверка дали SSL комуникацията с инстанцията на 389 работи. За целта може да използвайте инструмента openssl (в него имате възможност да симулирате работата на SSL клиент). За да може openssl да валидира сървърския сертификат, ще ви е нужно копие от този X.509 сертификат, който е на върха на сертификатната верига (за примера по-долу това е "SU ECC Root CA - uni-sofia.bg"). За да се снабдите с копие на сертификата, изпълнете (заменете съответните имена на директория и сертификат с тези, които са специфични за вашата инстанция):

# certutil -L -d /etc/dirsrv/slapd-hpc-service-host -n "SU ECC Root CA - uni-sofia.bg" -a > /tmp/ca.crt
# chmod 644 /tmp/ca.crt

След това, като напривилигерован потребител (не е нужно да сте super user), стартирайте openssl като клиент със следния набор от входящи параметри:

$ openssl s_client -connect localhost:636 -CAfile /tmp/ca.crt

и натиснете "Enter". Ако всичко (при сървъра и клиента) е конфигурирано правилно, в съобщенията на екрана ще видите блок с информация подобен на следния:

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 396269C3CD97190D95757CA5AE2FDC115CFCC2A60C3BED7B1F0AA549E57F9696
    Session-ID-ctx: 
    Master-Key: BF2DCCA63AFF0F22D6EF6BE00CD1FEDCDB837FB2F8CC2A1CFC5B7D218515B3FAAB648110D6AABB506DC7C8D558FD172F
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1554873687
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Обърнете специално внимание на това, което стои след Protocol и Cipher. Задължително след Protocol трябва да виждате TLSv1.2, а след Cipher, в края на реда, трябва да има SHA384. Натиснете клавишната комбинация Ctrl+C за да прекъснете установената SSL сесия.

Преди да започнете създаването на потребителските записи, трябва да инсталирате схемата за за поддържане на атрибути записи, съхраняващи OpenSSH публични ключове, а също така PKI схемата (която е специфична за тази HPC документация). За целта, изтеглете следните файлове:

98openssh.ldif

97pkcs7.ldif

и го поставете в директория /etc/dirsrv/slapd-instance_name (тук заменете instance_name с името на инстанцията). Установете съответните права за достъп и собственост върху файловете:

# chmod 640 97pkcs7.ldif
# chmod 640 98openssh.ldif
# chown dirsrv:dirsrv 97pkcs7.ldif
# chown dirsrv:dirsrv 98openssh.ldif

и след това рестартирайте инстанцията на 389:

# systemctl restart dirsrv@instance_name

(тук заменете instance_name с името на инстанцията). Всички операции, които са показани по-долу, може да изпълните на вашата потребителска система. Те не се нуждаят от локален достъп до сървърската система и еднственото, което е нужно да имате е мрежова свързаност до LDAP сървъра.

За да бъде възможно въвеждането на потребителската информация (POSIX акаунти/профили), които ще изпълняват задачи в HPC инфраструктурата, трябва да се създаде специално под-дърво в системата, върху което да може да бъде делегиран привилигерован достъп за мениджърите на потребителите.

Няма универсална схема, която да определя как точно да бъде дефинирано дървото с POSIX профилите. Показаната по-долу схема е просто една добра практика, но не бива да се разглежда като абсолютна и задължителна. В конкретния случай тя трябва да се адаптира към изискванията на конкретната HPC инфраструктура.

Примерите по-долу са дадени за следното поддърво в LDAP директорията:

o=unite-bg.eu
  |
  dc=HPC,o=unite-bg.eu
     |
     ou=Users,dc=HPC,o=unite-bg.eu
     |
     ou=Groups,dc=HPC,o=unite-bg.eu

За да може да работите с примерите по-долу без да е нужно да влизате в сървърската система и да изпълнявате там задачи, обърнете внимание на настройките, които трябва да направите върху клиентската система, от която ще изпълнявате задачите. Тези настройки са описани в документа "LDAP клиентски софтуер за достъп до LDAP сървъра". Това, което ви трябва, са инструкциите в секция 3 там.

За да бъдат създадени разклоненията на дървото, трябва да създадете файл (името на файла, използвано по-долу в примера е "setup_tree.ldif") със следното съдържание:

dn: dc=HPC,o=unite-bg.eu
dc: HPC
objectclass: dcObject
objectclass: top

dn: ou=Users,dc=HPC,o=unite-bg.eu
objectclass: organizationalUnit
objectclass: top
ou: Users

dn: ou=Groups,dc=HPC,o=unite-bg.eu
objectclass: organizationalUnit
objectclass: top
ou: Groups

След това, използвайки инструмента ldapadd, създайте поддървото по следния начин:

$ ldapadd -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "cn=Directory Manager" -x -W -a -f setup_tree.ldif

Ако операцията по създаването на поддървото е протекла успешно на сървъра, ще получите следния резултат от изпълнението на командния ред по-горе:

adding new entry "dc=HPC,o=unite-bg.eu"

adding new entry "ou=Users,dc=HPC,o=unite-bg.eu"

adding new entry "ou=Groups,dc=HPC,o=unite-bg.eu"

Може да прегледате дървото с изпълнението на

$ ldapsearch -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "cn=Directory Manager" -b "dc=HPC,o=unite-bg.eu" -x -W '' dn | grep -v ^#

Резултатът ще изглежда така и ще представя йерархията в дъвото:

dn: dc=HPC,o=unite-bg.eu

dn: ou=Users,dc=HPC,o=unite-bg.eu

dn: ou=Groups,dc=HPC,o=unite-bg.eu

search: 2
result: 0 Success

Нужно е да създадете потребител, или група потребители, с чиито dn ще могат да бъдат създавани, променяни и изтривани записите за потребителите и групите. Използването на dn-а cn=Directory Manager не се препоръчва за тези операции! Този потребител трябва да има правомощията за промяна само и единствено на записи в дървото, което е създадетно по рецептата дадена по-горе. Така се избягва възможността този потребител да получи контрол на всички записи в LDAP директорията.

Преди да съставите LDIF записа за този административен потребител, трябва да хеширате паролата, която той ще използва. Това може да стане така:

Инсталирайте dovecot формално на клиентската ви Linux система. Това, което ще ви трябва от този пакет е инструмента doveadm. За да генерирате хеширана парола чрез този инструмент, извикайте го по следния начин (като непривлигерован потребител):

Ще трябва да инсталирате пакета 389-ds-base

Под CentOS 7 и Scientific Linux 7, имате два лесни начина, по които може да инсталирате инструмент, чрез който да генерирате хеширана парола за потребителя:

• pwdhash

  Този инструмент е част пакета 389-ds-base. Което означава, че вече го имате инсталиран на LDAP сървърската система (защото там имате този пакет инсталиран). Не се препоръчва да използвате pwdhash върху сървърската система като root (super user). Или го използвайте там като непривилигерован потребител, или го инсталирайте на вашата клиентска система и там го използвайте също с правата на непривилигерован потребител.

  Генерирането на хеша на база на паролата става по следния начин (заменете password по-долу с реалната парола):

  $ pwdhash -s SHA512 password

• doveadm

  Този инструмент е част пакета dovecot. Най-вероятно той няма да е инсталиран на LDAP сървърската система. Може да го инсталирате на вашата клиентска система и там го използвайте с правата на непривилигерован потребител.

  Генерирането на хеша на база на паролата става по следния начин (трябва да въведете паролата двукратно в диалога, който ще се появи):

  $ doveadm pw -s SHA512

Все вдно кой от двата начина, показани по-горе, сте използвали за да генерирате хеша на паролата, той ще изглежда подобен на следния тест:

{SHA512}LCd5AVzrnMWonkZ6aeLbCCGDTxpd/zHQ5Y3Cv1UFDpex674X711O5oxpUZIT2Xqdzw4VSZpGfPne1kLBt9ZbaA==

ldap_add: Constraint violation (19)
	additional info: invalid password syntax - passwords with storage scheme are not allowed

Поради тази причина, когато създавате описанието на dn-обекта (преди да го изпратите до LDAP сървъра), не влагате в него паролата!

За примера по-долу, ще бъде създаден dn-обект "uid=useradmin,ou=Special Users,o=unite-bg.eu", който ще бъде използван за удостоверяване пред 389 LDAP директорийния сървър, с цел модифициране на дървото под "dc=HPC,o=unite-bg.eu". След като хеша на паролата е генериран (виж как по-горе), съставете следния dn (за примера по-долу се предполага, че тези записи ще бъдат записани във файла "useradmin.ldif"):

dn: uid=useradmin,ou=Special Users,o=unite-bg.eu
objectclass: account
objectclass: top
objectclass: inetUser
uid: useradmin

и го въведете в LDAP директорията с използване на ldapadd (това е инструмент от състава на пакета openldap-clients):

$ ldapadd -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "cn=Directory Manager" -x -W -a -f useradmin.ldif

След това, трябва да зададете паролата, като използвате процес на модификация на dn-обекта. Добавянето на атрибута userPassword (в него се съдържа хешираната парола) става като се създаде следния шаблон:

dn: uid=useradmin,ou=Special Users,o=unite-bg.eu
changetype: modify
replace: userPassword
userPassword: {SHA512}LCd5AVzrnMWonkZ6aeLbCCGDTxpd/zHQ5Y3Cv1UFDpex674X711O5oxpUZIT2Xqdzw4VSZpGfPne1kLBt9ZbaA==

и го запазете във файл, например "modify_user_password.ldif". След това, използвайки инструмента ldapmodify (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"), въведете промените:

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "cn=Directory Manager" -x -W -f modify_user_password.ldif

При успешно модифициране на потребителския dn-обект в LDAP директорията, ще получите следното съобщение (без нищо друго след него):

modifying entry "uid=useradmin,ou=Special Users,o=unite-bg.eu"

Последната стъпка в процеса е да делегирате правата, които потребител с този dn ("uid=useradmin,ou=Special Users,o=unite-bg.eu") ще има върху записите в дървото, които се намират под "dc=HPC,o=unite-bg.eu". Това става, като допълните dn-а на "dc=HPC,o=unite-bg.eu" с въвеждането в него на нов aci атрибут. За да го въведете, създайте файла "add_aci.ldif" и в него поставете следното съдържание:

dn: dc=HPC,o=unite-bg.eu
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "User Administrator"; allow (all) userdn="ldap:///uid=useradmin,ou=Special Users,o=unite-bg.eu";)

Запазете промените във файла и след това, чрез инструмента ldapmodify (това е инструмент от състава на пакета openldap-clients) въведете промените в LDAP директорията:

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "cn=Directory Manager" -x -W -f aci.ldif

При успешно изпълнение на горния команден ред (и правилен синтаксис на записите във файла ), ще получите потвърждение за успешна модификация на dn-а dc=HPC,o=unite-bg.eu:

modifying entry "dc=HPC,o=unite-bg.eu"

От този момент нататък, трябва да използвате потребителя с dn "uid=useradmin,ou=Special Users,o=unite-bg.eu", за да модифицирате съдържанието в "ou=Users,dc=HPC,o=unite-bg.eu" и "ou=Groups,dc=HPC,o=unite-bg.eu".