Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - 2life

Страницы: [1]
1
А по итогу всё работает :) Я ldapsearch сделал вот только сейчас.
Это не ошибка видимо, а предупреждение, про сертификат самоподписанный.
Вообщем виноват только сам, т.к. запутался между сертификатом, и ключом.
Большое спасибо! Вроде бы у меня вопросы закончились. Путь пройдён по настройке OpenLDAP.

2
Мой случай это второй случай (с самоподписанным сертификатом).  Вы правы, я указал файл ключа, а не сертификата, и даже не заметил этого J. Ошибку поправил.

Вывод команды следующий:

root@ldapsrv:/etc/ldap/tmp# ps ax | grep slapd
 9954 ?        Ssl    0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Ситуация с проверкой продвинулась дальше, но ненамного, к сожалению.

Вот так вроде нормально всё
root@ldapsrv:/etc/ldap/ssl# openssl verify -verbose -x509_strict -CAfile rootca.crt ldapsrv.domain.lan.crt
ldapsrv.domain.lan.crt: OK

Тут уже не очень...
root@ldapsrv:/etc/ldap/tmp# openssl s_client -connect ldapsrv.domain.lan:636 -showcerts -CApath /etc/ldap/ssl/
CONNECTED(00000003)
depth=1 C = RU, ST = CITY, L = CITY, O = COMPANY, OU = ITdept, CN = ca-server, emailAddress = info@domain.lan
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 C = RU, ST = CITY, L = CITY, O = COMPANY, OU = ITdept, CN = ca-server, emailAddress = info@domain.lan
verify return:1
depth=0 C = RU, ST = CITY, O = COMPANY, OU = ITdept, CN = ldapsrv.domain.lan, emailAddress = info@domain.lan
verify return:1

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3218 bytes and written 401 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self signed certificate in certificate chain)

Пока отправился гуглить.

3
Добрый день,
В целом и общем сервер OpenLDAP у меня прекрасно заработал. При запуске секция TLS была пропущена. Сейчас нужно к ней вернуться.
На данный момент при попытке подключится, через SSL получаю след. ошибку:

#ldapsearch -xZZLLLWD cn=admin,dc=domain,dc=lan -b cn=config -s base
ldap_start_tls: Connect error (-11)
        additional info: (unknown error code)
Без защиты:
/etc/ldap/tmp# ldapsearch -xLLLWD cn=admin,dc=domain,dc=lan -b cn=config -s base
Enter LDAP Password:
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: any
olcPidFile: /var/run/slapd/slapd.pid
olcTLSVerifyClient: never
olcToolThreads: 1
olcTLSCertificateFile: /etc/ldap/ssl/ldapsrv.domain.lan.crt
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldapsrv.domain.lan.key
olcTLSCACertificateFile: /etc/ldap/ssl/private/rootca.key

В логах вижу следующее:
Aug  9 19:01:46 fssrv2 slapd[23182]: connection_get(14): got connid=1001
Aug  9 19:01:46 fssrv2 slapd[23182]: connection_read(14): checking for input on id=1001
Aug  9 19:01:46 fssrv2 slapd[23182]: connection_read(14): unable to get TLS client DN, error=49 id=1001
Aug  9 19:01:46 fssrv2 slapd[23182]: conn=1001 fd=14 TLS established tls_ssf=256 ssf=256
Но т.к. используется TLSVerifyclient never, и на клиенте tls_reqcert "demand", то на ошибку «unable to get TLS client DN» можно внимание не обращать. Я верно понял?

При проверке через openssl картина такая:
root@ldapsrv:/etc/ldap/ssl# openssl s_client -connect 127.0.0.1:636 -CAfile /etc/ldap/ssl/ldapsrv.domain.lan.crt
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = RU, ST = CITY, O = COMPANY, OU = ITdept, CN = ldapsrv.domain.lan, emailAddress = info@domain.lan
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = RU, ST = CITY, O = COMPANY, OU = ITdept, CN = ldapsrv.domain.lan, emailAddress = info@domain.lan
verify error:num=21:unable to verify the first certificate
verify return:1
.......
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2143 bytes and written 373 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)


Опять я «забуксовал»...

4
Егор, ваш ответ можно считать образцовым. Всё описано подробно, но при этом вы использовали всего несколько абзацев. Читать приятно, и всё необычайно просто описано. Спасибо за вашу работу!
По поводу частной задачи вы правы, не стоит делать такие костыли. К тому же,  я подумал, при маппинге за всем этим добром придётся следить, всё таки нужно пересилить себя, и настроить LDAP клиентов на конечных машинах.

5
Извините, может я действительно усложнил что-то. И пользуюсь терминологией, к который привык из AD.
С NFS проблем сейчас нет, если работать под пользователями из LDAP-каталога.

Пользователя natalia я завёл как simpleSecurityObject, в выводе он есть, это была ошибка с моей стороны.

dn: uid=natalia,ou=users,dc=domain,dc=lan
uid: natalia
objectClass: account
objectClass: simpleSecurityObject
objectClass: top

На самом деле я уже завёл его (пользователя) нормально.

dn: cn=natalia,ou=users,dc=domain,dc=lan
uid: natalia
gecos: Natalia User
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 5003
gidNumber: 7000
homeDirectory: /home/natalia
cn: natalia

К сожалению, что я хочу сделать, не вышло.

Суть моего вопроса, что бы сервер LDAP понимал, что удалённый пользователь natalia (UID 1000) это доменный пользователь natalia@domain.lan (UID 5003).
Могу привести пример такого сопоставления на стороннем ресурсе
https://serverfault.com/questions/915119/nfsv4-mapping-uid-and-gid-on-debian-stretch
Только тут всё делается без LDAP, а непосредственно между локальными записями пользователей, на разных машинах.



6
Со второго сервера, на компьютере под локальной учетной записью, NFSv4 шара не монтировалось, т.к. там был фильтр *.domain.lan, сменил на 192.168.1.0/255.255.255.0 и всё заработало.
А нужно мне, что бы на компьютере работал локальный пользователь natalia, и его учётная запись маппилась с доменной natalia@domain.lan
Либо, не через маппинг, а что бы шара уже монтировалась с правами доменного пользователя.
Отвечаю на вопрос зачем так нужно. Т.к. компьютеров прилично (~20), и пока профиль переносить у всех нет возможности из локальной в доменную учётку. Хоть может быть это и просто копирование.
Спасибо.

7
Access Control List (ACL) / Re: Права доступа на NFS
« : 09 Август 2019, 11:16:08 »
У директории /srv/storage3 на сервере fssrv2 права rwxr-xrwx, то есть любой пользователь может писать и, следовательно, удалять дочерние объекты. Никакой магии =).

Как я понял, с предыдущей проблемой Вы разобрались?

Ну я просто смотрел на ACL с колокольни виндовой шары :) Спасибо.

Нет с той не разобрался, просто зашёл под пользователем LDAP в компьютер для тестирования NFS. Если возможно помочь в той теме, то буду благодарен.

8
Access Control List (ACL) / Права доступа на NFS
« : 09 Август 2019, 10:49:12 »
Настроил связку NFS + OpenLDAP на Ubuntu Server:

root@fssrv2:/srv/storage3# uname -a
Linux fssrv2 5.0.0-23-generic #24-Ubuntu SMP Mon Jul 29 15:36:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

root@fssrv2:/srv/storage3# exportfs -v
/srv/storage3   192.168.1.0/255.255.255.0(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

Создаю тестовую папку, у которой права только от пользователя LDAP

root@fssrv2:/srv/storage3# ls -la
total 1620008
drwxr-xrwx 5 root  root       4096 авг  9 07:41 .
drwxr-xr-x 3 root  root       4096 авг  7 10:09 ..
drwx------ 2 root  root      16384 авг  7 10:08 lost+found
drwx------ 2 test.user  root       4096 авг  9 10:46 test_root

На компьютере эти права видны прекрасно, в папку зайти не даёт, а удалить даёт(!)

natalia@NataS:/mnt/fssrv/storage3$ ls -la
итого 1620004
drwxr-xrwx 5 root    root         4096 авг  9 10:46 .
drwxr-xr-x 4 root    root            0 авг  9 10:24 ..
drwx------ 2 root    root        16384 авг  7 13:08 lost+found
drwx------ 2 test.user    root         4096 авг  9 10:46 test_root

natalia@NataS:/mnt/fssrv/storage3$ ls -la test_root/
ls: невозможно открыть каталог 'test_root/': Отказано в доступе
natalia@NataS:/mnt/fssrv/storage3$ rm test_root/
rm: невозможно удалить 'test_root/': Это каталог
natalia@NataS:/mnt/fssrv/storage3$ rm -rf test_root/

WTF?





9
Возможно ли на клиенте использовать локальную учётную запись, а через autofs использовать сетевые учетные данные?

Были настроены карты автоматического монтирования на сервере.

На клиенте локальная запись natalia, настроен AutoFS:

natalia@NataS:~$ sudo mount
....
ldap:ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan on /mnt/fssrv type autofs (rw,relatime,fd=7,pgrp=19919,timeout=600,minproto=5,maxproto=5,indirect,pipe_ino=240442)

natalia@NataS:~$ ls -la /mnt/fssrv/
итого 4
drwxr-xr-x 4 root root    0 авг  8 16:39 .
drwxr-xr-x 3 root root 4096 авг  8 16:39 ..
dr-xr-xr-x 2 root root    0 авг  8 16:39 storage2
dr-xr-xr-x 2 root root    0 авг  8 16:39 storage3

Директория storage2 сервер без LDAP, и файлы доступны. Директория storage3 c сервера на котором развёрнут LDAP, и в эту директорию попасть нельзя.

Так же с клиента проверяю работоспособность сервера:
natalia@NataS:~$ ldapsearch -xLLLWD cn=nssproxy,ou=users,dc=domain,dc=lan
Enter LDAP Password:
dn: dc=domain,dc=lan
objectClass: top
objectClass: dcObject
objectClass: organization
o: domain
dc: domain

dn: cn=admin,dc=domain,dc=lan
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

dn: ou=users,dc=domain,dc=lan
ou: users
objectClass: organizationalUnit
objectClass: top

dn: ou=groups,dc=domain,dc=lan
ou: groups
objectClass: organizationalUnit
objectClass: top

dn: ou=services,dc=domain,dc=lan
ou: services
objectClass: organizationalUnit
objectClass: top

dn: cn=nssproxy,ou=users,dc=domain,dc=lan
uid: nssproxy
gecos: Network Service Switch Proxy User
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/false
uidNumber: 801
gidNumber: 801
homeDirectory: /home/nssproxy
cn: nssproxy
userPassword:: e1NTSEF9aHZQWddsfffgFdkZHRTVVVVVkxmNFZrWlF2Y0Y=

dn: uid=natalia,ou=users,dc=domain,dc=lan
uid: natalia
objectClass: account
objectClass: simpleSecurityObject
objectClass: top

dn: cn=nssproxy,ou=groups,dc=domain,dc=lan
cn: nssproxy
objectClass: top
objectClass: posixGroup
gidNumber: 801
description: Network Service Switch Proxy

dn: cn=sysadmin,ou=groups,dc=domain,dc=lan
cn: sysadmin
objectClass: top
objectClass: posixGroup
gidNumber: 1100
description: UNIX systems administrators

dn: ou=autofs,ou=services,dc=domain,dc=lan
ou: autofs
objectClass: organizationalUnit
objectClass: top

dn: ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
ou: auto.nfs
objectClass: top
objectClass: automountMap

dn: ou=auto.master,ou=autofs,ou=services,dc=domain,dc=lan
ou: auto.master
objectClass: top
objectClass: automountMap

dn: cn=storage2,ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
objectClass: top
objectClass: automount
cn: storage2
automountInformation: 192.168.1.39:/fileserver/storage2/

dn: cn=storage3,ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
objectClass: top
objectClass: automount
cn: storage3
automountInformation: 192.168.1.29:/srv/storage3

dn: cn=/mnt/fssrv,ou=auto.master,ou=autofs,ou=services,dc=domain,dc=lan
objectClass: top
objectClass: automount
cn: /mnt/fssrv
automountInformation: ldap:ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
  --timeout=600 --ghost rsize=8192,wsize=8192

natalia@NataS:~$

natalia@NataS:~$ getent passwd nssproxy
nssproxy:x:801:801:Network Service Switch Proxy User:/home/nssproxy:/bin/false


Я так понимаю, что тут бы должен помочь Mapping? Только я не очень понимаю, где его настраивать, на клиенте, или на сервере.

И правильная ли такая конфигурация?
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = domain.lan

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = static,nsswitch
GSS-Methods = static,nsswitch

[Static]
natalia@domain.lan = natalia

Погуглив данную тему я обнаружил, что вроде без LDAP этот маппинг делают, но он работает не у всех. Во всех вопросах задаваемых в сети делали маппинг на стороне клиента. Но на одном из форумов я нашёл объяснение, что это задача сервера, и поэтому маппингом должен он заниматься. Кто прав не знаю.
В самом мане по NFSv4 информации на этот вопрос я не нашёл, или плохо читал...




10
Спасибо ) Вы решили этот мой вопрос. Пhодолжаю изучать OpenLDAP дальше. Для этого создам новую тему, т.к. кое-где уже застрялJ

11
Добрый день,
установлен Ubuntu Server 19.04 x64, настраиваю OpenLDAP первый раз, так что сильно не бейтеJ.

Сервер работает без ошибок:
root@fssrv2:/etc/ldap/schema# tail -f /var/log/slapd.log
Aug  8 08:49:34 fssrv2 slapd[23811]: daemon: shutdown requested and initiated.
Aug  8 08:49:34 fssrv2 slapd[23811]: slapd shutdown: waiting for 0 operations/tasks to finish
Aug  8 08:49:34 fssrv2 slapd[23811]: DIGEST-MD5 common mech free
Aug  8 08:49:34 fssrv2 slapd[23811]: DIGEST-MD5 common mech free
Aug  8 08:49:34 fssrv2 slapd[23811]: slapd stopped.
Aug  8 08:49:34 fssrv2 slapd[26823]:    ...done.
Aug  8 08:49:34 fssrv2 slapd[26830]:  * Starting OpenLDAP slapd
Aug  8 08:49:34 fssrv2 slapd[26844]: @(#) $OpenLDAP: slapd  (Ubuntu) (Jul 26 2019 17:21:00) $#012#011Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Aug  8 08:49:34 fssrv2 slapd[26846]: slapd starting
Aug  8 08:49:34 fssrv2 slapd[26830]:    ...done.

adm1n@fssrv2:~$ sudo ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'cn=config' dn
dn: cn=config

dn: cn=module{0},cn=config

dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}nis,cn=schema,cn=config

dn: cn={3}inetorgperson,cn=schema,cn=config

dn: cn={4}autofs,cn=schema,cn=config

dn: olcBackend={0}mdb,cn=config

dn: olcDatabase={-1}frontend,cn=config

dn: olcDatabase={0}config,cn=config

dn: olcDatabase={1}mdb,cn=config


Содержимое файла nssproxy.acl.ldif, впрочем как и в примере на сайте

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to *
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage
  by * break
-
add: olcAccess
olcAccess: {1}to attrs=userPassword
  by self write
  by anonymous auth
-
add: olcAccess
olcAccess: {2}to *
  by self read
  by dn.base="cn=nssproxy,ou=users,dc=domain,dc=lan" read

Получаю такую ошибку:
root@fssrv2:/etc/ldap/schema# ldapmodify -xWD cn=admin,dc=domain,dc=lan -f nssproxy.acl.ldif
Enter LDAP Password:
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

Поиск из мануала не отрабатывает:
root@fssrv2:/etc/ldap/schema# ldapsearch -xLLLWD cn=admin,dc=domain,dc=lan "(objectClass=*)"
Enter LDAP Password:
No such object (32)

Права у пользователя admin должны быть, так как весь каталог создавался им же. При установке отказался от пакета sudo-ldap, не очень понимаю зачем он там нужен. Так же сертификаты сделал, но что-то с ними не работает :)

Страницы: [1]