Created attachment 11561 [details] сообщение в Win7 Версия ====== Обнаружено в версии freeipa-server-4.9.10-alt0.p10.1 Дистрибутивы ============ * p10-server-10-x86-64 Шаги воспроизведения ==================== 1. Развернуть FreeIPA-сервер (домен: freeipa.testdomain), FreeIPA-реплику, ввести клиентов на без ALT Linux (например, p10-workstation) в домен. 2. Развернуть Windows AD (домен: tradex.tradtest), ввести клиент на Windows 7. 3. Настроить forwarder между контроллером домена FreeIPA и контроллером домена Windows AD: PS> dnscmd 127.0.0.1 /ZoneAdd freeipa.testdomain /Forwarder <FREEIPA_DC_IP> # ipa dnsforwardzone-add tradex.tradtest --forwarder=<WINDOWS_AD_DC_IP> --forward-policy=only 4. Выполнить установку доверия: # kinit admin && ipa trust-add --type=ad tradex.tradtest --admin Admin --password --two-way=true 5. Запросить сервер AD о его доверенных доменах: # ipa trust-fetch-domains tradex.tradtest # ipa trustdomain-find tradex.tradtest 6. Запросить service ticket для сервиса из IPA домена: # kvno -S host $(hostname) 7. Запросить service ticket сервиса из AD домена: # kvno -S cifs addc.tradex.tradtest Ожидаемый результат: получение сервисного тикета. Пример: cifs/addc.tradex.tradtest@: kvno = 3 Фактический результат: сообщение об ошибке kvno: Generic error (see e-text) while getting credentials for cifs/addc.tradex.tradtest@ Дополнительно: не работает вход доменным пользователем FreeIPA в машину, введённую в домен Windows AD (пишет "Недостаточно системных ресурсов для завершения операции", см. прикрепленный скриншот). При этом если задать доменному пользователю FreeIPA пароль со сменой пароля при следующем входе, то окно смена пароля на Windows вызывается и корректно работает (пароль действительно меняется, проверял на клиентах ALT Linux, но дальше такая же ошибка, как в скриншоте). Соответственно, на клиентах ALT Linux не монтируется общая папка через CIFS: # mount -v -t cifs -o user=aduser //<WINDOWS_AD_DC_IP>/share /mnt/adshare
p10, freeipa-server-4.9.14-alt0.p10.3 - ошибка актуальна
> Дополнительно: не работает вход доменным пользователем FreeIPA в машину, > введённую в домен Windows AD (пишет "Недостаточно системных ресурсов для > завершения операции", см. прикрепленный скриншот). При этом если задать > доменному пользователю FreeIPA пароль со сменой пароля при следующем входе, > то окно смена пароля на Windows вызывается и корректно работает (пароль > действительно меняется, проверял на клиентах ALT Linux, но дальше такая же > ошибка, как в скриншоте). Соответственно, на клиентах ALT Linux не > монтируется общая папка через CIFS: > > # mount -v -t cifs -o user=aduser //<WINDOWS_AD_DC_IP>/share /mnt/adshare https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/planning_identity_management/planning-a-cross-forest-trust-between-idm-and-ad_planning-identity-management#one-way-trusts-and-two-way-trusts_planning-a-cross-forest-trust-between-idm-and-ad In two way trusts, IdM users can authenticate to AD, and AD users can authenticate to IdM. AD users can authenticate to and access resources in the IdM domain as in the one way trust case. IdM users can authenticate but cannot access most of the resources in AD. They can only access those Kerberized services in AD forests that do not require any access control check. To be able to grant access to the AD resources, IdM needs to implement the Global Catalog service. This service does not yet exist in the current version of the IdM server.
> сообщение в Win7 > > Версия > ====== > > Обнаружено в версии freeipa-server-4.9.10-alt0.p10.1 > > Дистрибутивы > ============ > > * p10-server-10-x86-64 > > Шаги воспроизведения > ==================== > > 1. Развернуть FreeIPA-сервер (домен: freeipa.testdomain), FreeIPA-реплику, > ввести клиентов на без ALT Linux (например, p10-workstation) в домен. > 2. Развернуть Windows AD (домен: tradex.tradtest), ввести клиент на Windows > 7. > 3. Настроить forwarder между контроллером домена FreeIPA и контроллером > домена Windows AD: > > PS> dnscmd 127.0.0.1 /ZoneAdd freeipa.testdomain /Forwarder <FREEIPA_DC_IP> > > # ipa dnsforwardzone-add tradex.tradtest --forwarder=<WINDOWS_AD_DC_IP> > --forward-policy=only > > 4. Выполнить установку доверия: > > # kinit admin && ipa trust-add --type=ad tradex.tradtest --admin Admin > --password --two-way=true > > 5. Запросить сервер AD о его доверенных доменах: > > # ipa trust-fetch-domains tradex.tradtest > > # ipa trustdomain-find tradex.tradtest > > 6. Запросить service ticket для сервиса из IPA домена: > > # kvno -S host $(hostname) > > 7. Запросить service ticket сервиса из AD домена: > > # kvno -S cifs addc.tradex.tradtest > > Ожидаемый результат: получение сервисного тикета. Пример: > > cifs/addc.tradex.tradtest@: kvno = 3 > > Фактический результат: сообщение об ошибке > > kvno: Generic error (see e-text) while getting credentials for > cifs/addc.tradex.tradtest@ > Пожалуйста, проверьте по этой инструкции: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/installing_trust_between_idm_and_ad/index#verifying-the-kerberos-configuration_setting-up-a-trust
Created attachment 17707 [details] KRB5_TRACE https://issues.redhat.com/browse/RHEL-4910 - очень похоже на такую же ошибку. Прикрепляю файлом вывод команды # KRB5_TRACE=/dev/stderr kvno -S cifs addc.tradex.tradtest.
(In reply to Aleksandr Sysoev from comment #4) > Created attachment 17707 [details] > KRB5_TRACE > > https://issues.redhat.com/browse/RHEL-4910 - очень похоже на такую же > ошибку. > > Прикрепляю файлом вывод команды # KRB5_TRACE=/dev/stderr kvno -S cifs > addc.tradex.tradtest. Чтобы подтвердить, пожалуйста, прикрепите, krb5kdc.log.
Ошибка с запросом service ticket сервиса из AD домена не воспроизвелась. Полагаю, что дело было в том, что перед запросом сервисного тикета не получали билет из AD. То есть, перед запросом сервисного тикета выполнил: # kinit admin@tradex.tradtest После чего запрос сервисных тикетов успешно выполняется: # kvno -S cifs addc.tradex.tradtest cifs/addc.tradex.tradtest@TRADEX.TRADTEST: kvno = 3 # kvno -S host addc.tradex.tradtest host/addc.tradex.tradtest@TRADEX.TRADTEST: kvno = 3 # klist Ticket cache: KEYRING:persistent:0:krb_ccache_yyKGExa Default principal: admin@TRADEX.TRADTEST Valid starting Expires Service principal 10.02.2025 17:18:04 11.02.2025 03:12:09 host/addc.tradex.tradtest@TRADEX.TRADTEST renew until 11.02.2025 17:12:06 10.02.2025 17:12:11 11.02.2025 03:12:09 cifs/addc.tradex.tradtest@TRADEX.TRADTEST renew until 11.02.2025 17:12:06 10.02.2025 17:12:09 11.02.2025 03:12:09 krbtgt/TRADEX.TRADTEST@TRADEX.TRADTEST renew until 11.02.2025 17:12:06 Однако ошибка со входом доменным пользователем FreeIPA в машину, введённую в домен Windows AD осталась. Если в комментарии 2 (https://bugzilla.altlinux.org/show_bug.cgi?id=43852#c2) имелось ввиду, что это поведение ожидаемо, то ошибку можно закрывать.
(In reply to Aleksandr Sysoev from comment #6) > Ошибка с запросом service ticket сервиса из AD домена не воспроизвелась. > > Полагаю, что дело было в том, что перед запросом сервисного тикета не > получали билет из AD. То есть, перед запросом сервисного тикета выполнил: > # kinit admin@tradex.tradtest > > После чего запрос сервисных тикетов успешно выполняется: > # kvno -S cifs addc.tradex.tradtest > cifs/addc.tradex.tradtest@TRADEX.TRADTEST: kvno = 3 > # kvno -S host addc.tradex.tradtest > host/addc.tradex.tradtest@TRADEX.TRADTEST: kvno = 3 > > # klist > Ticket cache: KEYRING:persistent:0:krb_ccache_yyKGExa > Default principal: admin@TRADEX.TRADTEST > > Valid starting Expires Service principal > 10.02.2025 17:18:04 11.02.2025 03:12:09 > host/addc.tradex.tradtest@TRADEX.TRADTEST > renew until 11.02.2025 17:12:06 > 10.02.2025 17:12:11 11.02.2025 03:12:09 > cifs/addc.tradex.tradtest@TRADEX.TRADTEST > renew until 11.02.2025 17:12:06 > 10.02.2025 17:12:09 11.02.2025 03:12:09 > krbtgt/TRADEX.TRADTEST@TRADEX.TRADTEST > renew until 11.02.2025 17:12:06 Вы описали получение билета для пользователя AD и получение этим пользователем билета для сервиса из AD. До этого был другой сценарий (он же описан в https://issues.redhat.com/browse/RHEL-4910): получение билета для пользователя Idm(FreeIPA) и получение этим пользователем билета для сервиса из AD. В документации приведен третий случай. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/installing_trust_between_idm_and_ad/index#verifying-the-kerberos-configuration_setting-up-a-trust получение билета для пользователя AD и получение этим пользователем билета для сервиса из Idm(FreeIPA). > > Однако ошибка со входом доменным пользователем FreeIPA в машину, введённую в > домен Windows AD осталась. Если в комментарии 2 > (https://bugzilla.altlinux.org/show_bug.cgi?id=43852#c2) имелось ввиду, что > это поведение ожидаемо, то ошибку можно закрывать. Это поведение ожидаемо.
