Во-первых, разу уж настроил TLS, то надо лезть не по ldap://, а по ldaps://.
Во-вторых, рутовый сертификат, которым подписан сертфикат сервера, должен быть добавлен в доверенные на клиенте.
Во-третьих, раз у тебя AD на самбе, то видимо и Kerberos настроен, так и используй для шифрования Kerberos, а не TLS. ldapsearch прекрасно работает с GSSAPI (в этом случае нужно указывать ldap:// а не ldaps://).

тебе говорят, что ты при подключении должен использовать tls/ssl
(научись читать уже!)

если я не ошибаюсь, это параметр -zz у ldapsearch

Откуда в керберосе шифрование если он суть механизм аутентификаци???

Kerberos используется не только для аутентификации, но еще и для генерации общего сессионного ключа (см. skey в выводе «klist -e»), который клиент может использовать для чего угодно. Само шифрование делает SASL/GSSAPI.
После того, как клиент сделает SASLbind к LDAP-серверу по механизму GSSAPI, весь последующий трафик будет зашифрован.

Еще одна ошибка с ldapsearch

Благодарю за объяснение по ldap. Заклинание на самом сервере работает: ldapsearch -H ldap://localhost -Y GSSAPI -b «dc=epf,dc=lc» -D «CN=Administrator,CN=Users,DC=epf,DC=lc» -w Abc12345

На другой машине: ldapsearch -Y GSSAPI -b dc=epf,dc=lc -H ldap://sambaad.epf.lc -D «CN=Administrator,CN=Users,DC=epf,DC=lc» -w Abc12345

SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (Matching credential (ldap/192.168.16.4@168.16.4) not found) И непонятно даже где копать. На клиенте в krb5.conf:

[libdefaults]
        default_realm = EPF.LC
        dns_lookup_realm = false
        dns_lookup_kdc = true
# The following krb5.conf variables are only for MIT Kerberos.
#       krb4_config = /etc/krb.conf
#       krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# Thie only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).

#       default_tgs_enctypes = des3-hmac-sha1
#       default_tkt_enctypes = des3-hmac-sha1
#       permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

[realms]
        EPF.LC = {
                kdc = 192.168.16.4
                admin_server = 192.168.16.4
        }
        ATHENA.MIT.EDU = {
                kdc = kerberos.mit.edu:88
                kdc = kerberos-1.mit.edu:88
                kdc = kerberos-2.mit.edu:88
                admin_server = kerberos.mit.edu
                default_domain = mit.edu
        }
        MEDIA-LAB.MIT.EDU = {
                kdc = kerberos.media.mit.edu
                admin_server = kerberos.media.mit.edu
        }
        ZONE.MIT.EDU = {
                kdc = casio.mit.edu
                kdc = seiko.mit.edu
                admin_server = casio.mit.edu
        }
        MOOF.MIT.EDU = {
                kdc = three-headed-dogcow.mit.edu:88
                kdc = three-headed-dogcow-1.mit.edu:88
                admin_server = three-headed-dogcow.mit.edu
        }
        CSAIL.MIT.EDU = {
                kdc = kerberos-1.csail.mit.edu
                kdc = kerberos-2.csail.mit.edu
                admin_server = kerberos.csail.mit.edu
                default_domain = csail.mit.edu
                krb524_server = krb524.csail.mit.edu
        }
        IHTFP.ORG = {
                kdc = kerberos.ihtfp.org
                admin_server = kerberos.ihtfp.org
        }
        GNU.ORG = {
                kdc = kerberos.gnu.org
                kdc = kerberos-2.gnu.org
                kdc = kerberos-3.gnu.org
                admin_server = kerberos.gnu.org
        }
        1TS.ORG = {
                kdc = kerberos.1ts.org
                admin_server = kerberos.1ts.org
        }
        GRATUITOUS.ORG = {
                kdc = kerberos.gratuitous.org
                admin_server = kerberos.gratuitous.org
        }
        DOOMCOM.ORG = {
                kdc = kerberos.doomcom.org
                admin_server = kerberos.doomcom.org
        }
        ANDREW.CMU.EDU = {
                kdc = kerberos.andrew.cmu.edu
                kdc = kerberos2.andrew.cmu.edu
                kdc = kerberos3.andrew.cmu.edu
                admin_server = kerberos.andrew.cmu.edu
                default_domain = andrew.cmu.edu
        }
        CS.CMU.EDU = {
                kdc = kerberos.cs.cmu.edu
                kdc = kerberos-2.srv.cs.cmu.edu
                admin_server = kerberos.cs.cmu.edu
        }
        DEMENTIA.ORG = {
                kdc = kerberos.dementix.org
                kdc = kerberos2.dementix.org
                admin_server = kerberos.dementix.org
        }
        stanford.edu = {
                kdc = krb5auth1.stanford.edu
                kdc = krb5auth2.stanford.edu
                kdc = krb5auth3.stanford.edu
                master_kdc = krb5auth1.stanford.edu
                admin_server = krb5-admin.stanford.edu
                default_domain = stanford.edu
        }
        UTORONTO.CA = {
                kdc = kerberos1.utoronto.ca
                kdc = kerberos2.utoronto.ca
                kdc = kerberos3.utoronto.ca
                admin_server = kerberos1.utoronto.ca
                default_domain = utoronto.ca
        }

[domain_realm]
        .mit.edu = ATHENA.MIT.EDU
        mit.edu = ATHENA.MIT.EDU
        .media.mit.edu = MEDIA-LAB.MIT.EDU
        media.mit.edu = MEDIA-LAB.MIT.EDU
        .csail.mit.edu = CSAIL.MIT.EDU
        csail.mit.edu = CSAIL.MIT.EDU
        .whoi.edu = ATHENA.MIT.EDU
        whoi.edu = ATHENA.MIT.EDU
        .stanford.edu = stanford.edu
        .slac.stanford.edu = SLAC.STANFORD.EDU
        .toronto.edu = UTORONTO.CA
        .utoronto.ca = UTORONTO.CA

[login]
        krb4_convert = true
        krb4_get_tickets = false

Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Administrator@EPF.LC

Valid starting Expires Service principal 07/17/2018 07:01:01 07/17/2018 17:01:01 krbtgt/EPF.LC@EPF.LC renew until 07/18/2018 07:00:53

Ты точно в команде ldapsearch указывал DNS-имя ldap://sambaad.epf.lc, а не IP-адрес?

Судя по сообщению:

Matching credential (ldap/192.168.16.4@168.16.4) not found

ldapsearch у тебя пытается получить тикет для ldap/192.168.16.4@168.16.4, причем в качестве REALM берет 168.16.4. Это неправильно, таких принципалов нет в AD, о чем собственно он и говорит "(not found)". Нужно, чтобы он пытался получить тикет для ldap/sambaad.epf.lc@EPF.LC.

Kerberos сильно зависит от настройки DNS (и от того, что у тебя в /etc/hosts).

В krb5.conf лучше пропиши нормальное DNS-имя, зачем тебе IP-адреса?

        EPF.LC = {
                kdc = 192.168.16.4
                admin_server = 192.168.16.4
        }

Раз уж полагаешься на статические REALM'ы, то и пропиши их соответствующим образом:

[domain_realm]
.epf.lc = EPF.LC
epf.lc = EPF.LC

Либо, если у тебя в DNS корректно настроены SRV-записи, ты можешь выставить в krb5.conf «dns_lookup_realm = true» и вообще убрать из него EPF.LC и все остальные realm'ы.

А всякий мусор типа MIT.EDU, STANFORD.EDU, UTORONTO.CA и все, что относится к Kerberos V4 убрать по-любому, где ты это откопал вообще?

re:Еще одна ошибка с ldapsearch

Проблема в кривом DNS. Добавил адрес в хостс и все заработало. Когда запускаю рсатовскую консоль для DNS у меня вместо имени DNS написан его ip

1)Ты точно в команде ldapsearch указывал DNS-имя ldap://sambaad.epf.lc, а не IP-адрес?

Точно.Даже историю в putty посмотрел.

2)В krb5.conf лучше пропиши нормальное DNS-имя, зачем тебе IP-адреса?

Привычка использовать везде ip, ну и отсутствие тяги к прекрасному:)

3)А всякий мусор типа MIT.EDU, STANFORD.EDU, UTORONTO.CA и все, что относится к Kerberos V4 убрать по-любому, где ты это откопал вообще?

До этого была ошибка что-то типа «не могу найти файл или каталог». И сначала решил, что чего-то недоустановил, и как результат поставил кучу ненужного хлама, даже запускал интерактивный конфигуратор для krb5, поэтому он так и засран. Это потом до меня дошло, что дело может быть в билете, а точнее в его отсутствие :)

И еще один вопрос. Изначальная цель - перетащить учетки из ad в NextCloud. Но в результате не получался даже запрос по ldapsearch, теперь этот этап пройден, но в вебморде лдапиться NextCloud не хочет.В форме надо ввести пользователя и имя сервера , порт. Запрос ldapsearch в ролики(https://www.youtube.com/watch?v=naMyXKDVSgY – 6 мин) ютуба отличается от моего. (нет -Y GSSAPI). Сам вопрос:«Что проще «сконфигурировать» веб-сервер или керберос?» Заранее благодарен:)

поправка

Вопрос не правильный)) веб-сервер или лдап-сервер

Kerberos проще, если он уже настроен и работает, и есть понимание, как он работает :)
Если же настраивать с нуля, то конечно же TLS понять и настроить проще.

Если цель - просто перетащить учетки, то вариантов масса:

• Использовать TLS (ldaps:// в URL)
• Сделать kinit от имени пользователя, от которого запущена web-морда. У меня ldapsearch при сделанном kinit использует GSSAPI, даже если не указан ключ -Y GSSAPI. Если же очень хочется ключик -Y, соответствующую опцию можно прописать в ldaprc, .ldaprc или переменную окружения $LDAP<option-name>. Насколько я понимаю, опция назвается SASL_MECH.
• Отключить strong auth в самбе, тогда можно будет биндиться несекьюрно (это плохо, т.к. пароль будет передаваться открытым текстом)

  [global]
  ldap server require strong auth = no
  

Не хочет запускаться с -Y GSSAPI по умолчанию

почитал https://www.mkssoftware.com/docs/man5/ldap_config.5.asp

echo 'export LDAPSASL_MECH=GSSAPI' >> /etc/environment

source /etc/environment

проверка

printenv | grep LDAP

LDAPSASL_MECH=GSSAPI

Запуск: ldapsearch -b dc=epf,dc=lc -H ldap://sambaad.epf.lc -D «CN=Administrator,CN=Users,DC=epf,DC=lc» -w Tga12345 ldap_bind: Strong(er) authentication required (8) additional info: BindSimple: Transport encryption required.

Попробовал создать файл ldaprc, но тут несколько вопросов:

1)В чем разница между ldaprc и .ldaprc?

2)Файл надо создавать в рабочем каталоге? То есть если

cat /etc/passwd

www-data:x:33:33:www-data:/var/www:/bin/bash

надо создавать в /var/www?

3)Формат записи параметров в фале как в ldap.conf или /etc/environment?

4)Нужно ли х+?

Вообще это неправильно - использовать в командной строке одновременно и логин/пароль, и GSSAPI. Это же взаимоисключающие механизмы. Для GSSAPI не нужны логин/пароль, он игнорирует эти опции (ему достаточно тикета).

Если хочешь использовать GSSAPI, то не указывай логин/пароль вообще, GSSAPI будет пробоваться по умолчанию (даже без опции -Y).

Если хочешь использовать парольную аутентификацию - указывай логин/пароль и не указывай GSSAPI.

Почему опция -Y перебивает парольную аутентификацию только тогда, когда она явно указана в командной строке - могу предположить, что явно указанные в командной строке опции логина/пароля «сильнее», чем неявная -Y, заданная через переменную окружения или конфиг-файл.

Если твое приложение намертво прибито гвоздями к парольной аутентификации, то юзай TLS, делов-то.

С nextcloud по tls прокатило, а потом решил поковырять MyDlp там нет возможности в веб-морде указать ldaps:// или ldap:// и все прибито гвоздями к парольной аутентификации.

Самба показывает варианты:

supportedSASLMechanisms: GSS-SPNEGO

supportedSASLMechanisms: GSSAPI

supportedSASLMechanisms: NTLM

Попробовал через NTLM(ldapsearch -Y NTLM -h sambaad.epf.lc -D Administrator@epf.lc -W), но ругается на учетку, хотя через tls аутентификация успешна. Можно через переменные окружения указать, что надо использовать tls?И не нашел ничего внятного про GSS-SPNEGO.Что это?

Не уверен, что SASL/NTLM поддерживает шифрование.
Я использовал только GSSAPI.

Можно через переменные окружения указать, что надо использовать tls?

Без понятия. Думаю, ты уже достаточно въехал в тему, чтобы покопаться в документации (на худой конец, в исходниках), и ответить сам на этот вопрос.

И не нашел ничего внятного про GSS-SPNEGO.Что это?

Это тоже механизм прозрачной аутентификации (как и Kerberos), но может использовать еще и NTLM в дополнение к Kerberos. Например, если для сервера не зарегистрирован SPN (а значит Kerberos в пролете), то клиент молча посылает ему NTLM-хэш твоего пароля вместо Kerberos-тикета.

Часто используется для SSO на Web-сайтах (метод HTTP Negotiate).