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

За да създадете POSIX група, трябва да асоциирате към нея уникален групов номер и уникално име (името трябва да отговаря на POSIX стандарта). В този случай изберете цяло число равно или по-голямо от 1000 и по-малко или равно на 60000.

В НИКАКЪВ СЛУЧАЙ не задавайте стойност на gidNumber за POSIX група в LDAP, по-малка от 1000! В CentOS 7 и Scientific Linux 7 всички POSIX групи с GID < 1000 са служебни!

Къде са дефинирани тези ограничения за числото, което може да се използва за GID в CentOS 7 и Scientifi Linux 7? Те са дефинирани във файла /etc/login.defs (вижте там деклрациите GID_MIN и GID_MAX). Не е желателно да променяте стойностите там, освен ако не ги промените на всички изчисителни сървъри в HPC инфраструктурата.

Всички примери, използвани по-долу, следват структурата на LDAP дървото установена в документа "Инсталиране и конфигуриране на 389 директориен сървър за удостоверяване на потребителите в HPC под CentOS 7 и Scientific Linux 7". Ако структурата на това дърво е различна във вашия случай, трябва да направите съответните промени, когато следвате примерите дадени по-долу.

Преди да започнете процедурата по създаване на нова POSIX група в "ou=Groups,dc=HPC,o=unite-bg.eu", трябва да проверите кой е най-високия GID номер на група там (ако има поне една таква дефинирана там). Това може да направите като изпълните следния примерен команден ред (може да се наложи да замените името на хоста hpc-service-host.unite.uni-sofia.bg с това на вашия LDAP сървър и dn на потребителя (за примера това е uid=useradmin,ou=Special Users,o=unite-bg.eu) с който ще се удостоверявате пред сървъра):

$ ldapsearch -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W | awk '/gidNumber: / {print $2}' | sort | tail -n 1

Отбележете, че инструмента ldapsearch е част от пакета openldap-servers. Конфигурацията на SSL за използването на инструментите е описана в документа "LDAP клиентски софтуер за достъп до LDAP сървъра".

След като определите най-високия GID номер, може да изберете този за новата група. Ако определения преди това максимален GID е под 1000, то за новата POSIX група може да се използвате GID равно на 1000. В случаяй, че е по-голям от 1000, то новия GID може да бъде определения преди това максимален GID плюс 1. Създаването на нова POSIX група в LDAP директорията може да стане на базата на следния LDIF шаблон (името на групата е стойността на атрибута cn, а GID номера е стойността на атрибута gidnumber):

dn: cn=users,ou=Groups,dc=HPC,o=unite-bg.eu
cn: users
gidnumber: 1000
objectclass: posixGroup
objectclass: top

Запазете текста с шаблона във файл, например "create_group.ldif" и използвайте инструмента ldapadd, който е част от пакета openldap-clients, за да създадете dn-обекта на групата (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"):

$ ldapadd -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -a -f create_group.ldif

Заменете името на хост на LDAP сървъра hpc-service-host.unite.uni-sofia.bg, използвано в примера, с актуалното във вашия случай и dn на потребителя, с чиито права ще се удостоверите пред LDAP сървъра (заменете uid=useradmin,ou=Special Users,o=unite-bg.eu с актуалния при вас)! При успешно създаване на новата POSIX група в LDAP директорията, ще получите следния резултат (без нищо след него):

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

Членовете на една POSIX група са обикновено POSIX потребители (понякога може и членове на една група да станат автоматично и членове на друга група, но този случай не се разглежда тук). Тези потребители се изброяват с техните uid (POSIX потребителски имена).

В примера по-долу е показано как да се добави потребител с POSIX потребителско име vesso към POSIX групата с име queue. За целта съставете шаблона:

dn: cn=queue,ou=Groups,dc=HPC,o=unite-bg.eu
changetype: modify
add: memberUid
memberUid: vesso

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

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f add_user_to_group.ldif

Заменете името на хост на LDAP сървъра hpc-service-host.unite.uni-sofia.bg, използвано в примера, с актуалното във вашия случай и dn на потребителя, с чиито права ще се удостоверите пред LDAP сървъра (заменете uid=useradmin,ou=Special Users,o=unite-bg.eu с актуалния при вас)! При успешно добавяне на потребителя към POSIX групата в LDAP директорията, ще получите следния резултат (без нищо след него):

modifying entry "cn=queue,ou=Groups,dc=HPC,o=unite-bg.eu"

ВНИМАНИЕ! Когато един POSIX група е основна за POSIX потребител, той не се декларира като нейн член. Вместо това уникалния номер на групата (gidNumber) се задава като атрибут в dn-обекта на потребителя! Следователно, не очаквайте при изпълнението на горния команден ред, да видите като стойности на memberUid потребиелите, за които тази група е основна!

Примерът по-долу показва как да се изведе списъка с POSIX потребители, които са членове на POSIX групата queue и която не е основна, а допълнителна POSIX група за тези потребители (ако беше основна, те нямаше да са описани като стойност на memberUid атрибута). Извеждането ще е в резултат от използването инструмента ldapsearch (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"), по следния начин:

$ ldapsearch -o ldif-wrap=no -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -b "ou=Groups,dc=HPC,o=unite-bg.eu" -x -W 'cn=queue' memberUid | grep ^memberUid

Заменете името на хост на LDAP сървъра hpc-service-host.unite.uni-sofia.bg, използвано в примера, с актуалното във вашия случай и dn на потребителя, с чиито права ще се удостоверите пред LDAP сървъра (заменете uid=useradmin,ou=Special Users,o=unite-bg.eu с актуалния при вас)! При наличие на атрибути memberUid, ще бъде изведен резултат подобен на следния:

memberUid: vesso
memberUid: test001
memberUid: test002

ВНИМАНИЕ! Не може да използвате примера по-долу за да изтриете POSIX потребител от основнаа му POSIX група, доколкото тя е указана в самия dn-обект на потребителя!

Изтриването (прекратяване на членството) на POSIX потребител от POSIX група, декларирана в LDAP директорията, става като се премахне съответния memberUid атрибут (който съдържа потребителското име) от dn-обекта на групата. В примера по-долу е показано как да бъде изтрит POSIX потребителя vesso от POSIX групата queue. Съставте шаблона:

dn: cn=queue,ou=Groups,dc=HPC,o=unite-bg.eu
changetype: modify
delete: memberUid
memberUid: vesso

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

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f remove_user_from_group.ldif

Заменете името на хост на LDAP сървъра hpc-service-host.unite.uni-sofia.bg, използвано в примера, с актуалното във вашия случай и dn на потребителя, с чиито права ще се удостоверите пред LDAP сървъра (заменете uid=useradmin,ou=Special Users,o=unite-bg.eu с актуалния при вас)! При успешно изтриване на потребителя към POSIX групата в LDAP директорията, ще получите следния резултат (без нищо след него):

modifying entry "cn=queue,ou=Groups,dc=HPC,o=unite-bg.eu"

За да изтриете POSIX група от LDAP директорията, може да използвате инструмента ldapdelete от пакета openldap-clients. Описание на настройките на SSL, използвани от инструментите в този пакет е дадено в документа "LDAP клиентски софтуер за достъп до LDAP сървъра").

В примера, даден по-долу, е показано как да изтриете POSIX групата "users", представена в LDAP дървото с dn-обект "cn=users,ou=Groups,dc=HPC,o=unite-bg.eu":

$ ldapdelete -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W "cn=users,ou=Groups,dc=HPC,o=unite-bg.eu"

При успешно изтриване, няма да бъде изведен резултат от изпълнение на горния команден ред.

Отбележете, че името на dn-а на групата е оградено в кавички в края на командния ред по-горе (това е задължително). Във вашия случай може да се наложи да замените името на хост на сървъра hpc-service-host.unite.uni-sofia.bg с това на вашия сървър.

За да декларирате POSIX потребител, трябва да асоциирате към него уникално потребителско име, уникален потребителски номер, уникален номер на POSIX групата, която е основна (подразбираща се за този потребител). Потребителското име (uid) трябва да отговаря на POSIX стандарта, а уникалния номер на POSIX група (gidNumber) е на група, която вече съществува (виж "Деклариране на POSIX групи в LDAP директорията"). За уникален номер (uidNumber) на потребителя изберете цяло число равно или по-голямо от 1000 и по-малко или равно на 60000.

В НИКАКЪВ СЛУЧАЙ не задавайте за POSIX потребител в LDAP директорията стойност на uidNumber, която е по-малка от 1000! В CentOS 7 и Scientific Linux 7 всички POSIX потребители с uidNumber < 1000 са служебни!

Къде са дефинирани тези ограничения за числото, което може да се използва за UID в CentOS 7 и Scientifi Linux 7? Те са дефинирани във файла /etc/login.defs (вижте там деклрациите UID_MIN и UID_MAX). Не е желателно да променяте стойностите там, освен ако не ги промените на всички изчисителни сървъри в HPC инфраструктурата.

Всички примери, използвани по-долу, следват структурата на LDAP дървото, установена в документа "Инсталиране и конфигуриране на 389 директориен сървър за удостоверяване на потребителите в HPC под CentOS 7 и Scientific Linux 7". Ако структурата на това дървто е различна във вашия случай, трябва да направите съответните промени, когато следвате и прилагате примерите.

Преди да започнете процедурата по създаване на нов POSIX потребител в "ou=Users,dc=HPC,o=unite-bg.eu", трябва да проверите кой е най-високата стойност на uidNumber на потребител там (ако има поне един потребител дефиниран там). Това може да направите като изпълните следния примерен команден ред (може да се наложи да замените името на хоста hpc-service-host.unite.uni-sofia.bg с това на вашия LDAP сървър):

$ ldapsearch -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W | awk '/uidNumber: / {print $2}' | sort | tail -n 1

Отбележете, че инструмента ldapsearch е част от пакета openldap-servers, а конфигурацията на SSL за използването на инструментите е описана в документа "LDAP клиентски софтуер за достъп до LDAP сървъра".

След като определите най-високата стойност на uidNumber, може да изберете този за новия потребител по следния начин. Ако определения преди това максимален uidNumber е под 1000, то за новитя POSIX потребител може да се назначи uidNumber равен на 1000. В случаяй, че uidNumber е по-голям от 1000, то новия може да бъде определения преди това максимален uidNumber плюс 1. Освен да изберете uidNumber, трябва да знаете и коя ще бъде подразбиращата се POSIX група и при създаването на dn-обекта за потребителя да я зададете като стойност на gidNumber. Ще трябва и да изберете какъв команден интерпретатор да назначите (в повечето случаи това ще е /bin/bash).

Най-важната стъпка е задаването на парола за потребителя. Тя се задава СЛЕД като dn-обекта на потребителя е създаден! Защо се налага паролата да бъде зададена СЛЕД като dn-обекта на потребителя е създаен? Паролите, които са запазени като атрибут в dn-ите в LDAP директорията, НЕ БИВА да са явни (в открит текст). Поради това те трябва да бъдат запазени в хеширан формат. 389 LDAP директорийният сървър поддържа използването на хеширани пароли, базирани на хеш-функции като SSHA, SHA, SHA256, SHA348 и SHA512 (препоръчително е да използвате последната, макар това е обект на дискусия). LDAP сървърът, по подразбиране, прилага проверка на синтаксиса на паролите, които потребителите задават (или сменят) след като се удостоверят пред сървъра. Което означава, че по подразбиране 389 очаква потребителя да се свърже към сървъра, да се удостовери, да изпрати новата парола в явен вид (този протокол се нарича "LDAP bind") и чак след като LDAP сървърския процес я провери спрямо зададените в него политики за здравина, да я приеме, хешира и запише като атрибут в dn-а на потребителя. Следователно, ако се опитате да направите шаблон за създаване на нов потребител и в него зададете хешираната парола, 389 няма да създаде потребителя и ще изведе следното съобщение за грешка:

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

Именно затова паролата се поставя в dn-а в хеширан вид СЛЕД като той се създаде, като процес на редакция на dn-атрибута userPassword (така е направено по-долу в примерите).

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

• pwdhash

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

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

  $ pwdhash -s SHA512 password

• doveadm

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

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

  $ doveadm pw -s SHA512

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

{SHA512}LCd5AVzrnMWonkZ6aeLbCCGDTxpd/zHQ5Y3Cv1UFDpex674X711O5oxpUZIT2Xqdzw4VSZpGfPne1kLBt9ZbaA==

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

Създаването на dn-обекта (без паролата в него), може да стане съгласно следния шаблон, в който се предполага, че потребителското POSIX име ще бъде vesso, домашната директория на потребителя ще бъде /home/vesso, командния интерпретатор ще е /bin/bash, а uidNumber и gidNumber ще бъдат 1000/1000:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
cn: Veselin Kolev
gidnumber: 1000
givenname: Veselin
homedirectory: /home/vesso
loginshell: /bin/bash
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
objectclass: organizationalPerson
objectclass: person
sn: Kolev
uid: vesso
uidnumber: 1000

Запазете шаблона във файла create_user.ldif и след това използвайте инструмента ldapadd, който е част от пакета openldap-clients, за да създадете dn-обекта (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"):

$ ldapadd -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -a -f create_user.ldif

Заменете името на хост на LDAP сървъра hpc-service-host.unite.uni-sofia.bg (използвано в примера), с актуалното във вашия случай! При успешно създаване на новата POSIX група в LDAP директорията, ще получите следния резултат (без нищо друго след него):

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

Сега може да пристъпите към задаването на паролата под формата на изчисления по-горе хеш. Това става като съставите шаблон за модификация на dn-а:

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

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

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f modify_user_password.ldif

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

modifying entry "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

За да изтриете POSIX потребител от LDAP директорията, може да използвате инструмента ldapdelete от пакета openldap-clients. Описание на настройките на SSL, използвани от инструментите в този пакет е дадено в документа "LDAP клиентски софтуер за достъп до LDAP сървъра").

В примера, даден по-долу, е показано как да изтриете POSIX потребителя с потребителско име "vesso", представен в LDAP дървото с dn-обект "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu":

$ ldapdelete -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

като удостоверяването пред сървъра става с dn uid=useradmin,ou=Special Users,o=unite-bg.eu. При успешно изтриване, няма да бъде изведен резултат от изпълнение на горния команден ред.

Отбележете, че името на dn-а на потребителя е оградено в кавички в края на командния ред по-горе (това е задължително!!!). Във вашия случай може да се наложи да замените името на хост на сървъра hpc-service-host.unite.uni-sofia.bg с това на вашия сървър.

Отбележете, че този метод за удостоверяване на се използва от 389 LDAP сървъра да удостоверява LDAP потребители (т.е. потребителя не може да промени своя dn-обект удостоверявайки се пред LDAP сървъра чрез OpenSSH ключ, а само с парола). Ползата от задаването на OpenSSH в dn-обекта на потребителя е за удостоверяване на потребителя пред HPC порталните сървъри. На тези сървъри има скрипт, който проверява dn-обектите на потребителите, извлича копие от OpenSSH ключовете им и ги поставя в съответните authorized_keys файлове.

Схемата, която поддържа поставянето на OpenSSH публични ключове в LDAP директорията, трябва да е вече налична в инсталацията на 389 сървъра, ако той е инсталиран съгласно инструкциите в документа "Инсталиране и конфигуриране на 389 директориен сървър за удостоверяване на потребителите в HPC под CentOS 7 и Scientific Linux 7" (за подробности вижте там "Създаване на дървото за HPC POSIX потребителите и групите").

След като сте създали потребителски dn-обект по начина, който е описан по-горе, добавянето на атрибут за съхранение на OpenSSH ключ става на база на следния шаблон:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
add: objectClass
objectClass: ldapPublicKey
-
add: sshpublickey
sshpublickey: ecdsa-sha2-nistp384 AAAAE2VjZHNhLXNoYTItbmlzdHAzODQAAAAIbmlzdHAzODQAAABhBGRLqlM68gZnhJxKbzgJLmY/N20WfMH2Stylzai3KxmY13V6yQV2lc7DLR/GI5+KKCyagDy2A9wd2BkH5BHnN6uOaRKeqXA1iVvOFMwHkEOEjIkO+Wm2MwyKZUGJBKnUFA== vesso-01-apr-2019

В примера ще бъде добаве OpenSSH публичен ключ в dn-обекта uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu. Ако този шаблон е запазен във файла add_openssh_key.ldif, добавянето на атрибутите към потребителския dn може да стане чрез инструмента ldapmodify (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"):

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f add_openssh_key.ldif

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

modifying entry "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

Подмяната на OpenSSH ключа, съхранен като атрибут в потребителския dn-обект в LDAP директорията, става по следния начин. Съставете шаблона:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
replace: sshpublickey
sshpublickey: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEAqq4ppSD79Pt6nplVpFEIRjJ3/IlvN4YFmYUhtR81CyZVWU6hkH3LqHx+utvl+lWajOgKZajxQAhqGK+SGuz7uV5yHvo4I4yF6Am9S16L2j8XYTTYcNgRcFlOMGp251+HF+ZtkZ/jcAMcMaoM1NvLiN3XQJZk3da9Kib2Lrg7QnbLnAqWGdTF6MPg7NhXp735e8hpr17zYTXu4fiDidqPhElhJL9b55UMknX99+DS8FEn9azyomLv+UfBK/iczo5GN65NSBBV0Dq5DPzwKayxrrVdGmbESNXkRuIUBTjvJkvtmdrKwAuYPLRknb9XkMp4oQ3la8gfnPcXWvm8jvStPW3uuUDDqykS/Ot7dFmDStQG/nldF9qiak3j62UGCZq+emZ6zMILox7F/WPiAQBgo12bjzSqUS3mJ7R1khpsdaLegAzSCujhkho8voRSBFD0jWuywVAYIXMPNXJivvnEkB2VPTL77oInHUuu3XMbrfkK6JJCDlViZsgecol5yvIgUE667eqsVIvsAzu59n0tS+UVHlmwW+dtxyvkjTHo/mK307PgSXiFSRtjpPtXf9OsTkrIMnO3VWpF1l3PBruo+QbaPWzCCv3c7fRct25pfMCKDisa5eQw0pEl83Wa0Y3ft8qbzs5p3FwH2FVB00PZp36lfZYUKQ4lzDuAvCDdHkM= vlk-05-mar-2007

(предполага се, че подмяната касае dn-обекта "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu") в който след sshpublickey: трябва да поставите новия OpenSSH ключ. Ако този шаблон бъде запазен във файла replace_openssh_key.ldif, подмяната на OpenSSH ключа в потребителския dn може да стане използвайки инструмента ldapmodify (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"):

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f replace_openssh_key.ldif

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

modifying entry "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

В някои случаи може да се наложи да изтриете OpenSSH ключа на потребителя. За да се изтрие атрибута, който съдържа OpenSSH ключа, трябва да се изтрие и обектния клас "ldapPublicKey". Инструкциите за това се поставят в шаблон, който е подобен на следния (предполага се, че изтриването засяга dn-обекта "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"):

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
delete: sshpublickey
-
delete: objectClass
objectClass: ldapPublicKey

Ако запазите този шаблон във файла "replace_openssh_key.ldif", изтриването на OpenSSH ключа (и съответния обектен клас) в потребителския dn може да стане така, използвайки инструмента ldapmodify (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"), въведете промените:

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f replace_openssh_key.ldif

Възможно е при вас името на хост на LDAP сървъра да не е hpc-service-host.unite.uni-sofia.bg (заменете го с това на вашия LDAP сървър). При успешно изтриване, ще получите следното съобщение (без нищо друго след него):

modifying entry "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

Потребителите (сами или с помощта на администратор) могат да поставят своите X.509 сертификати в техните dn-обекти, като целта е тези сертификати да могат да бъдат използвани за да се извлече от тях публичния ключ, който да има ролята на публичен OpenSSH ключ и да бъде употребен за удостоверяване на потребителя в HPC инфраструктурните портали (от където потребителите изпращат задачите в опашката). По този начин се създава връзка между PKI инфраструктура на даден Удостоверител и публичните OpenSSH ключове, използвани в HPC. От изключителна важност е да има САМО ЕДИН X.509 сертификат записан в потребителския dn-обект (има само един OpenSSH публичен ключ за dn-обект, съгласно LDAP схемата, която е възприета тук и инсталирана в инстанцията на 389 LDAP сървъра).

X.509 сертификати могат да бъдат запазвани като атрибут "userCertificate" в dn-обектите на потребителските сертификати, без да е нужно да влагате никакви допълнителни обектни класове, ако тези dn-обекти са създадени съгласно рецептата дадена по-горе. За да бъде поставен като стойност на "userCertificate", X.509 сертификата трябва да бъде конвертиран в бинарен формат (формат "DER") и след това да се кодира в BASE64 формат (по-долу е показано как става това).

Преди да продължите с операцията по поставяне или подмяна на X.509 сертификат в dn-обект на потребител, трябва да разполагате с копие от сертификата във файл. За примерите по-долу се приема, че това е файла certificate.crt. Освен това, X.509 сертификата на потребителя се съхранява в dn-обекта на POSIX потребителя специфично форматиран. Това означава, че съставянето на стойността на атрибута "userCertificate" изисква предварителна обработка на блока със сертификата. Проверете дали X.509 сертификата във файла certificate.crt е във формат "PEM" или "DER". От това зависи по-нататъшния процес по генерирането на стойността на "userCertificate". Тази проверка може да направите като следвате инструкциите в "Приложение 1: Как да определим дали един X.509 сертификат е във формат PEM или DER", част от документа "LDAP клиентски софтуер за достъп до LDAP сървъра". След като сте определили формата на съхранения във файла сертификат, трябва да създадете записа за стойността на атрибута "userCertificate" (за примерите по-долу, създадения атрибут "userCertificate" ще се запише във файла userCertificate.ldif):

• X.509 сертификата е в "PEM" формат:

  $ echo -n "userCertificate: " > userCertificate.ldif && openssl x509 -inform PEM -in certificate.crt -outform DER | base64 -w0 >> userCertificate.ldif

• X.509 сертификата е в "DER" формат:

  $ echo -n "userCertificate: " > userCertificate.ldif && base64 -w0 certificate.crt >> userCertificate.ldif

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

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
replace: userCertificate

Добавете в края на файла съдържанието на userCertificate.ldif:

$ cat userCertificate.ldif >> replace_certificate.ldif

Накрая, въведете промените в dn-обекта с използване на инструмента ldapmodify (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"):

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f replace_openssh_key.ldif

Възможно е при вас името на хост на LDAP сървъра да не е hpc-service-host.unite.uni-sofia.bg (заменете го с това на вашия LDAP сървър). При успешно въвеждане или замяна на X.509 сертификата, ще получите следното съобщение (без нищо друго след него):

modifying entry "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

Потребителят може сам да постави или подмени сертификата в своя dn-обект, като изпълни горната операция с ldapmodify, задавайки своя dn след "-D". Това може да стане и през phpldapadmin.

Ако желаете да подмените сертификата в dn-обекта с нов, използвайте същата процедура, която сте използвали за поставянето на предишния сертификат (тази, обяснена тук).

За да изтриете X.509 сертификат, който е записан като "userCertificate" атрибут в dn-обекта на POSIX потребител в LDAP, без да го замените с друг, трябва да изтриете атрибута. Това може да стане като създадете първо шаблон с описание на операцията по изтриването и след това го прочетете с инструмента ldapmodify.

В примера по-долу е показано как да бъде изтрит атрибута "userCertificate" от dn-а uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu (заменете този dn с актуалния във вашия случай). Създайте шаблона:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
delete: userCertificate

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

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f del_userCertificate.ldif

Възможно е при вас името на хост на LDAP сървъра да не е hpc-service-host.unite.uni-sofia.bg (заменете го с това на вашия LDAP сървър). При успешно изтриване на X.509 сертификата, ще получите следното съобщение (без нищо друго след него):

modifying entry "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

ВНИМАНИЕ! Потребителят може да изтрие сертификата в своя dn-обект, като изпълни горната операция с ldapmodify, задавайки своя dn след "-D". Това може да стане и през phpldapadmin.

За да можете да извлечете само публичния ключ от X.509 сертификата, който е част от POSIX потребителския dn-обект, трябва да използвате инструмента ldapsearch (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра") по следния начин:

$ ldapsearch -o ldif-wrap=no -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu" -b "ou=Users,dc=HPC,o=unite-bg.eu" -x -W 'uid=vesso' userCertificate | grep ^userCertificate | awk '{print $2}' | base64 -d | openssl x509 -inform DER -noout -pubkey > pubout.pem

В този команден ред трябва да замените dn-а след "-D" с актуалния (на потребителя или администратора на потребители, в зависимост от ситуацията) и да направите същото и за името на хост на сървъра (hpc-service-host.unite.uni-sofia.bg). Публичният ключ ще бъде съхранен във файла pubout.pem. Така запазеният публичен ключ може да се форматира до OpenSSH формат и да се запази като такъв във файла openssh.pem така:

$ ssh-keygen -i -m PKCS8 -f pubout.pem > openssh.pem

Форматираният OpenSSH публичен ключ от файла openssh.pem може да поставите в dn-обекта на POSIX потребителя, като използвате инструкциите в "Задаване на OpenSSH ключ като метод за удостоверяване на потребителя" (ако в dn-обекта няма OpenSSH ключ в момента) или "Задаване на OpenSSH ключ като метод за удостоверяване на потребителя".

Защо е нужно цифрово подписване на OpenSSH ключа в dn-обекта на POSIX потребителя? Потребителите ще влизат в командния интерпретатор на HPC порталните сървъри на база на OpenSSH ключ валидиране, а не на база валидна парола (удостоверяване с парола трябва да се избягва на всяка цена). Което означава, че трябва да се предотврати възможността за подмяната на този ключ в LDAP директорията при евентуален "пробив" с възможност за редакция на dn-обекти. Идеята зад цифровото подписване е, че използваеми са само тези OpenSSH ключове, които са цифрово пописани от администратор на системата и този подпис е валиден.

ВНИМАНИЕ! Цифровото подписване на обектите в dn-обекта на POSIX потребителя, се извършва чрез частния ключ към потребителския сертификат на администратора на потребителски профили (потребителите не подписват своите атрибути, това прави само администратора, след като установи автентичността на съдържанието им). Ако подписването става чрез openssl (препоръчително), то съответните ключове и сертификати, които openssl може да чете, могат да бъдат извадени от PKCS#12 форматирания блок, както е показано в "Приложение 1. Дизасемблиране на PKCS#12 блок до съставните му частен ключ и X.509 сертификати".

Изтеглете копие от OpenSSH ключа на потребителя от LDAP директорията (за примера се предполага, че това е OpenSSH ключа, който се намира в dn-обекта uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu, а хост името на LDAP сървъра е hpc-service-host.unite.uni-sofia.bg). Това може да направите с използване на инструмента ldapsearch (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"):

$ ldapsearch -o ldif-wrap=no -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -b "ou=Users,dc=HPC,o=unite-bg.eu" -x -W 'uid=vesso' sshpublickey | grep ^sshpublickey | awk '{print $2" "$3}' > openssh.pub && sed -i '$s/$/ vesso/' openssh.pub

След това съдържанието на openssh.pub се подписва цифрово по следния начин (пак повтаряме, това се извършва от администратор, а не от POSIX потребителя):

$ openssl cms -binary -sign -in openssh.pub -inkey admin_key.pem -signer admin_cert.pem -certfile sub_ca.pem -out openssh.pub.p7b -outform DER -md sha384 -nodetach

където файла admin_key.pem съдържа частния ключ на администратора, admin_cert.pem съдържа X.509 сертификата на администратора, а admin_chain.pem има в себе си сертификатната верига, допълваща удостоверяването до сертификата на Издателя на сертификата (CA)..

За да поставите подписаното съдържание в dn-обект на POSIX потребителя, съставете шаблона:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
add: objectClass
objectClass: pkcs7
-
add: sshpublickey-p7b

и го запазете като файла add_signature.ldif (не допускайте добавянето на нов ред след "add: sshpublickey-p7b"). Подписаното съдържание във файла openssh.pub.p7b е в двоичен формат и за да се добави към шаблона, то трябва да бъде конвертирано в BASE64 формат, и да се постави в края на записите:

$ echo -n "sshpublickey-p7b::" `base64 -w0 openssh.pub.p7b` >> add_signature.ldif

След последната операция, съдържанието на файла с шаблона (add_signature.ldif) ще изглежда така:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
add: objectClass
objectClass: pkcs7
-
add: sshpublickey-p7b
sshpublickey-p7b:: MIIItQYJKoZIhvcNAQcCoIIIpjCCCKICAQExDTALBglghkgBZQMEAgIwgeQGCSqGSIb3DQEHAaCB1gSB02VjZHNhLXNoYTItbmlzdHAzODQgQUFBQUUyVmpaSE5oTFhOb1lUSXRibWx6ZEhBek9EUUFBQUFJYm1semRIQXpPRFFBQUFCaEJHUkxxbE02OGdabmhKeEtiemdKTG1ZL04yMFdmTUgyU3R5bHphaTNLeG1ZMTNWNnlRVjJsYzdETFIvR0k1K0tLQ3lhZ0R5MkE5d2QyQmtINUJIbk42dU9hUktlcVhBMWlWdk9GTXdIa0VPRWpJa08rV20yTXd5S1pVR0pCS25VRkE9PSB2ZXNzbwqgggXKMIICzjCCAi+gAwIBAgIEB8kW5TAKBggqhkjOPQQDBDA+MRUwEwYDVQQKDAx1bmktc29maWEuYmcxDDAKBgNVBAsMA3BraTEXMBUGA1UEAwwOU1UgRUNDIFJvb3QgQ0EwHhcNMTkwMzEzMjE1NjM1WhcNMzkwMjI2MDIzMjAyWjBNMRUwEwYDVQQKEwx1bmktc29maWEuYmcxDDAKBgNVBAsTA3BraTEmMCQGA1UEAxMdU1UgRUNDIElkZW50aXR5IE1hbmFnZW1lbnQgQ0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQuQPnvmO8UHUSSkuNr47XgU00EBELtS/LmpWWfbl7Q3v16NY0m27LaxNiIhmorqELhhquUOl1KYywjjE0DYE/RXPEHQ7hQ0ATYBf981kOchlDJacLXsePl/i1gIXRRMW+jge4wgeswHwYDVR0jBBgwFoAUE44W9vH6EIikLNchib81QTTiGE0wHQYDVR0OBBYEFBPqpmvcIg2kepwJ3XuuCZZC+e3zMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMEcGCCsGAQUFBwEBBDswOTA3BggrBgEFBQcwAYYraHR0cDovL3BraS51bmktc29maWEuYmcvb2NzcC9TVV9FQ0NfUm9vdF9DQTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vcGtpLnVuaS1zb2ZpYS5iZy9jcmwvU1VfRUNDX1Jvb3RfQ0EuY3JsMAoGCCqGSM49BAMEA4GMADCBiAJCAXcOjodaJsptN67Wbm2NId542Ui3RxlYL3g1rjOjmyjft1wFM5ldf97AzbamvKzIKSHdaVc9MgrzgdkbRkx6FIIMAkIAxRJ0KXxZJ4LqKtGnaB6CL1DGTzAGBUvXPXkI18lKdsvS62mj3kBBBUy/8wejnMcWFT8lZeGMXuLNmEmqu5E2ZlkwggL0MIICeaADAgECAgQBUO1rMAoGCCqGSM49BAMDME0xFTATBgNVBAoTDHVuaS1zb2ZpYS5iZzEMMAoGA1UECxMDcGtpMSYwJAYDVQQDEx1TVSBFQ0MgSWRlbnRpdHkgTWFuYWdlbWVudCBDQTAeFw0xOTAzMTQyMDUwNDlaFw0yMjAzMTMyMDUwNDlaMD4xFjAUBgNVBAMTDVZlc2VsaW4gS29sZXYxJDAiBgkqhkiG9w0BCQEWFXZsa0BsY3BlLnVuaS1zb2ZpYS5iZzB2MBAGByqGSM49AgEGBSuBBAAiA2IABGRLqlM68gZnhJxKbzgJLmY/N20WfMH2Stylzai3KxmY13V6yQV2lc7DLR/GI5+KKCyagDy2A9wd2BkH5BHnN6uOaRKeqXA1iVvOFMwHkEOEjIkO+Wm2MwyKZUGJBKnUFKOCATcwggEzMB8GA1UdIwQYMBaAFBPqpmvcIg2kepwJ3XuuCZZC+e3zMFYGCCsGAQUFBwEBBEowSDBGBggrBgEFBQcwAYY6aHR0cDovL3BraS51bmktc29maWEuYmcvb2NzcC9TVV9FQ0NfSWRlbnRpdHlfTWFuYWdlbWVudF9DQTAOBgNVHQ8BAf8EBAMCA9gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDkGA1UdEQQyMDCgLgYKKwYBBAGCNxQCA6AgDB5hbm9ueW1vdXNAZWFwLXRscy51bmktc29maWEuYmcwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3BraS51bmktc29maWEuYmcvY3JsL1NVX0VDQ19JZGVudGl0eV9NYW5hZ2VtZW50X0NBLmNybDAKBggqhkjOPQQDAwNpADBmAjEAmWSoI5QOd9u2/QfdvfuR3hjgiaDOmDUs62DaW3kcys8LmpPOEsXfSZ6BoRUC7f76AjEAgjmsnEqquEGsI5JMI0yKi+AKjAQKPPHebRIh6ViuQ011CwOPJH6As+TpfpygkHB1MYIB1zCCAdMCAQEwVTBNMRUwEwYDVQQKEwx1bmktc29maWEuYmcxDDAKBgNVBAsTA3BraTEmMCQGA1UEAxMdU1UgRUNDIElkZW50aXR5IE1hbmFnZW1lbnQgQ0ECBAFQ7WswCwYJYIZIAWUDBAICoIH0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDQzMDA1NDc0MVowPwYJKoZIhvcNAQkEMTIEMHS8KQJOL5tq3w6r6JJWElnllad4KHb/bx/ECxZpjvhcxkEE7H8skpMEz2Qz91jj4jB5BgkqhkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAKBggqhkjOPQQDAwRnMGUCMAX7v/Vl0OUVV3lAjzSS6tL7tca0HMUfqhQJcjJWxYF43LBXu85SuZzuB1bU6SY8pgIxALeY1sR1Bn+ahvs5iMKVQGvee/lWevt5NrND90QjfB53zAhIA2wOar0+NF0/a1qotg==

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

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f add_openssh.pub.p7b.ldif

В този случай следвайте инструкциите в "Цифрово подписване на OpenSSH ключовете в dn-обекта на POSIX потребител", но заменете началото на шаблона:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
add: objectClass
objectClass: pkcs7
-
add: sshpublickey-p7b

с

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
replace: sshpublickey-p7b

Всички други инструкции са същите.

$ ldapsearch -o ldif-wrap=no -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -b "ou=Users,dc=HPC,o=unite-bg.eu" -x -W 'uid=vesso' sshpublickey-p7b | grep ^sshpublickey-p7b

Ако в dn-обекта на POSIX потребителя съществува цифрово подписан OpenSSH ключ, зададен като стойност на атрибута sshpublickey-p7b, ще бъде изведен резултат, който е подобен на следния:

sshpublickey-p7b:: MIIItQYJKoZIhvcNAQcCoIIIpjCCCKICAQExDTALBglghkgBZQMEAgIwgeQGCSqGSIb3DQEHAaCB1gSB02VjZHNhLXNoYTItbmlzdHAzODQgQUFBQUUyVmpaSE5oTFhOb1lUSXRibWx6ZEhBek9EUUFBQUFJYm1semRIQXpPRFFBQUFCaEJHUkxxbE02OGdabmhKeEtiemdKTG1ZL04yMFdmTUgyU3R5bHphaTNLeG1ZMTNWNnlRVjJsYzdETFIvR0k1K0tLQ3lhZ0R5MkE5d2QyQmtINUJIbk42dU9hUktlcVhBMWlWdk9GTXdIa0VPRWpJa08rV20yTXd5S1pVR0pCS25VRkE9PSB2ZXNzbwqgggXKMIICzjCCAi+gAwIBAgIEB8kW5TAKBggqhkjOPQQDBDA+MRUwEwYDVQQKDAx1bmktc29maWEuYmcxDDAKBgNVBAsMA3BraTEXMBUGA1UEAwwOU1UgRUNDIFJvb3QgQ0EwHhcNMTkwMzEzMjE1NjM1WhcNMzkwMjI2MDIzMjAyWjBNMRUwEwYDVQQKEwx1bmktc29maWEuYmcxDDAKBgNVBAsTA3BraTEmMCQGA1UEAxMdU1UgRUNDIElkZW50aXR5IE1hbmFnZW1lbnQgQ0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQuQPnvmO8UHUSSkuNr47XgU00EBELtS/LmpWWfbl7Q3v16NY0m27LaxNiIhmorqELhhquUOl1KYywjjE0DYE/RXPEHQ7hQ0ATYBf981kOchlDJacLXsePl/i1gIXRRMW+jge4wgeswHwYDVR0jBBgwFoAUE44W9vH6EIikLNchib81QTTiGE0wHQYDVR0OBBYEFBPqpmvcIg2kepwJ3XuuCZZC+e3zMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMEcGCCsGAQUFBwEBBDswOTA3BggrBgEFBQcwAYYraHR0cDovL3BraS51bmktc29maWEuYmcvb2NzcC9TVV9FQ0NfUm9vdF9DQTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vcGtpLnVuaS1zb2ZpYS5iZy9jcmwvU1VfRUNDX1Jvb3RfQ0EuY3JsMAoGCCqGSM49BAMEA4GMADCBiAJCAXcOjodaJsptN67Wbm2NId542Ui3RxlYL3g1rjOjmyjft1wFM5ldf97AzbamvKzIKSHdaVc9MgrzgdkbRkx6FIIMAkIAxRJ0KXxZJ4LqKtGnaB6CL1DGTzAGBUvXPXkI18lKdsvS62mj3kBBBUy/8wejnMcWFT8lZeGMXuLNmEmqu5E2ZlkwggL0MIICeaADAgECAgQBUO1rMAoGCCqGSM49BAMDME0xFTATBgNVBAoTDHVuaS1zb2ZpYS5iZzEMMAoGA1UECxMDcGtpMSYwJAYDVQQDEx1TVSBFQ0MgSWRlbnRpdHkgTWFuYWdlbWVudCBDQTAeFw0xOTAzMTQyMDUwNDlaFw0yMjAzMTMyMDUwNDlaMD4xFjAUBgNVBAMTDVZlc2VsaW4gS29sZXYxJDAiBgkqhkiG9w0BCQEWFXZsa0BsY3BlLnVuaS1zb2ZpYS5iZzB2MBAGByqGSM49AgEGBSuBBAAiA2IABGRLqlM68gZnhJxKbzgJLmY/N20WfMH2Stylzai3KxmY13V6yQV2lc7DLR/GI5+KKCyagDy2A9wd2BkH5BHnN6uOaRKeqXA1iVvOFMwHkEOEjIkO+Wm2MwyKZUGJBKnUFKOCATcwggEzMB8GA1UdIwQYMBaAFBPqpmvcIg2kepwJ3XuuCZZC+e3zMFYGCCsGAQUFBwEBBEowSDBGBggrBgEFBQcwAYY6aHR0cDovL3BraS51bmktc29maWEuYmcvb2NzcC9TVV9FQ0NfSWRlbnRpdHlfTWFuYWdlbWVudF9DQTAOBgNVHQ8BAf8EBAMCA9gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDkGA1UdEQQyMDCgLgYKKwYBBAGCNxQCA6AgDB5hbm9ueW1vdXNAZWFwLXRscy51bmktc29maWEuYmcwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3BraS51bmktc29maWEuYmcvY3JsL1NVX0VDQ19JZGVudGl0eV9NYW5hZ2VtZW50X0NBLmNybDAKBggqhkjOPQQDAwNpADBmAjEAmWSoI5QOd9u2/QfdvfuR3hjgiaDOmDUs62DaW3kcys8LmpPOEsXfSZ6BoRUC7f76AjEAgjmsnEqquEGsI5JMI0yKi+AKjAQKPPHebRIh6ViuQ011CwOPJH6As+TpfpygkHB1MYIB1zCCAdMCAQEwVTBNMRUwEwYDVQQKEwx1bmktc29maWEuYmcxDDAKBgNVBAsTA3BraTEmMCQGA1UEAxMdU1UgRUNDIElkZW50aXR5IE1hbmFnZW1lbnQgQ0ECBAFQ7WswCwYJYIZIAWUDBAICoIH0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDQzMDA1NDc0MVowPwYJKoZIhvcNAQkEMTIEMHS8KQJOL5tq3w6r6JJWElnllad4KHb/bx/ECxZpjvhcxkEE7H8skpMEz2Qz91jj4jB5BgkqhkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAKBggqhkjOPQQDAwRnMGUCMAX7v/Vl0OUVV3lAjzSS6tL7tca0HMUfqhQJcjJWxYF43LBXu85SuZzuB1bU6SY8pgIxALeY1sR1Bn+ahvs5iMKVQGvee/lWevt5NrND90QjfB53zAhIA2wOar0+NF0/a1qotg==

Този резулат гарантира, че атрибута sshpublickey-p7b съществува и следователно (ако това се налага), може да бъде изтрит. За да се изтрие, трябва да съставите следния шаблон (заменете dn-а с конкретния във вашия случай), който може да запазите във файла del_openssh.pub.p7b.ldif:

dn: uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu
changetype: modify
delete: objectClass
objectClass: pkcs7
-
delete: sshpublickey-p7b

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

$ ldapmodify -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -x -W -f del_openssh.pub.p7b.ldif

Заменете името на хоста на LDAP сървъра (за примера това е hpc-service-host.unite.uni-sofia.bg) с това на вашия LDAP сървър и dn-обекта на потребителя, с чиито права ще се заяви изтриването (за примера това е uid=useradmin,ou=Special Users,o=unite-bg.eu, но във вашия случай този dn може да е друг). При успешно изтриване ще получите следния резултат от изпълнението на горния команден ред (и нищо друго след него):

modifying entry "uid=vesso,ou=Users,dc=HPC,o=unite-bg.eu"

ВНИМАНИЕ! Терминология - потребителски X.509 сертификат - това е сертификат, издаден от сертификатен удостоверител, който служи за цифрово подписване на електронна поща и/или файлове, удостоверяване пред сървърски системи, криптиране на информация и който не може да издава (удостоверява) други X.509 сертификати. Това не означава, че потребителския сертификат е сертификат само на POSIX потребител, описан в LDAP директорията. Този сертификат може да се използва и от администратора на потребители в LDAP директорията, за да подписва цифрово техни атрибути.

За всички примери по-долу, файла admin.p12 съдържа PKCS#12 форматиран блок, който включва потребителския X.509 сертификат, частния ключ към него, както и сертификатната верига, която валидира сертификата (във веригата се съдържат удостоверителски X.509 сертификати).

• запазване на частния ключ към сертификата на потребителя като криптиран PEM форматиран блок в текстов файл:

  Изпълете командния ред:

  $ openssl pkcs12 -in admin.p12 -out admin_key.pem -nocerts

  Ще бъде изискано въвеждането на паролата за декптиране на PKCS#12 блока:

  Enter Import Password:

  след което ще трябва да въведете два пъти последователно парола, с която ключа ще бъде защитен (криптиран) във файла admin_key.pem:

  Enter PEM pass phrase:
  Verifying - Enter PEM pass phrase:

  В резултат от изпълнението на горния команден ред, частния ключ от PKCS#12 блока ще бъде изведен и запазен криптиран във файла admin_key.pem.

• запазване на X.509 сертификата на потребителя (в случая - администратора на потребители в LDAP директорията) като PEM форматиран блок в текстов файл:

  Изпълнете командния ред:

  $ openssl pkcs12 -in admin.p12 -out admin_cert.pem -clcerts -nokeys

  Ще бъде изискано въвеждането на паролата за декптиране на PKCS#12 блока:

  Enter Import Password:

  след което X.509 сертификата на потребителя ще бъде запазен в PEM формат във файла admin_cert.pem.

• запазване на веригата от X.509 удостоверителски сертификати като PEM форматирани блокове в текстов файл:

  Изпълнете командния ред:

  $ openssl pkcs12 -in admin.p12 -out admin_chain.pem -cacerts -nokeys

  Ще бъде изискано въвеждането на паролата за декптиране на PKCS#12 блока:

  Enter Import Password:

  след което веригата от сертификати на потребителя ще бъде запазена в PEM формат (един или няколко PEM блока - в зависимост колко сертификата има в нея) във файла admin_chain.pem.