PowerScale OneFS: Провайдер Active Directory зникає після спроби приєднання до того ж домену

Після виконання AD-з'єднання з тією ж назвою, що й провайдер AD, до якого кластер вже підключений, провайдер може зникнути. Адміністратори можуть побачити помилку, пов'язану з спробою приєднання, хоча ця помилка може змінюватися залежно від причини.

У наведеному нижче прикладі ми відтворюємо проблему з провайдером TESTDOMAIN.LOCAL Використання неправильного акаунта для полегшення приєднання

.Вихідні дані з isi auth status і isi auth ads list -v показати, що провайдер присутній перед виконанням команди:

corebuddy-1# isi auth status
ID                                            Active Server                Status
----------------------------------------------------------------------------------
lsa-activedirectory-provider:TESTDOMAIN.LOCAL winserv2019.testdomain.local online
lsa-activedirectory-provider:DOMAIN2.LOCAL    domain2DC1.domain2.local     online
lsa-local-provider:System                     -                            active
lsa-local-provider:test                       -                            active
lsa-local-provider:domain2                    -                            active
lsa-file-provider:System                      -                            active
----------------------------------------------------------------------------------
Total: 6

corebuddy-1# isi auth ads list -v | grep -i testdomain
                     Name: TESTDOMAIN.LOCAL
           Primary Domain: TESTDOMAIN.LOCAL
                   Forest: testdomain.local
           NetBIOS Domain: TESTDOMAIN
                 Hostname: corebuddy.testdomain.local

Нижче ми виконуємо команду. Зверніть увагу, що вказано неправильне ім'я користувача (наприклад, ми використали назву групи для «Адміністратори » замість облікового запису адміністратора ):

corebuddy-1# isi auth ads create --name=TESTDOMAIN.LOCAL --user=administrators
password:
Failed to join domain 'TESTDOMAIN.LOCAL' account 'corebuddy' user 'administrators@TESTDOMAIN.LOCAL': (LW_ERROR_KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN) Client not found in Kerberos database

Тепер провайдера немає. У WebUI це може виглядати як нестилізоване, але в CLI це не відображається у вихідних файлах для isi auth status.

orebuddy-1# isi auth status
ID                                         Active Server            Status
---------------------------------------------------------------------------
lsa-activedirectory-provider:DOMAIN2.LOCAL domain2DC1.domain2.local online
lsa-local-provider:System                  -                        active
lsa-local-provider:test                    -                        active
lsa-local-provider:domain2                 -                        active
lsa-file-provider:System                   -                        active
---------------------------------------------------------------------------
Total: 5

Оскільки статус ISI auth може свідчити про відсутність провайдера з інших причин, ми повинні це додатково підтвердити. Командування isi auth ads list -v не відображає жодного виходу, що відповідає провайдеру TESTDOMAIN.LOCAL нижче. Це означає, що конфігурація не містить записів, які відповідають відсутній області області.

corebuddy-1# isi auth ads list -v |grep -i test
corebuddy-1#

Журнали LSASS показують подібні помилки, які спостерігаються під час виконання початкової команди:

2024-06-11T21:25:21.298318+00:00 <30.4> corebuddy-1(id1) lsass[5467]: [LwKrb5GetTgtImpl /b/mnt/src/isilon/fsp/lwadvapi/threaded/krbtgt.c:247] KRB5 Error code: -1765328378 (Message: Client 'administrators@TESTDOMAIN.LOCAL' not found in Kerberos database)
2024-06-11T21:25:21.299207+00:00 <30.4> corebuddy-1(id1) lsass[5467]: [lsass] Error occurred while joining domain: Error code: 41737 (symbol: LW_ERROR_KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN)

Вищезазначений сценарій не обмежується використанням неправильних облікових даних. Якщо існує будь-яка умова, яка може призвести до відмови приєднатися до провайдера AD, то це призводить до видалення провайдера. Наприклад, якщо однакова назва облікового запису машини використовується в іншому місці лісу або в довіреному домені, це призводить до збою. Єдина різниця може бути в наданій помилці.

При виконанні AD-з'єднання проти вже підключеного домену наявність умов, які могли б спричинити відмову, призводить до видалення провайдера AD. Це зроблено навмисно, оскільки OneFS розглядає це як спробу «повернення». Коли виникає збій, будь-яка конфігурація, пов'язана з цим провайдером автентифікації, видаляється.

corebuddy-1# isi auth status
ID                                         Active Server            Status
---------------------------------------------------------------------------
lsa-activedirectory-provider:DOMAIN2.LOCAL domain2DC1.domain2.local online
lsa-local-provider:System                  -                        active
lsa-local-provider:test                    -                        active
lsa-local-provider:domain2                 -                        active
lsa-file-provider:System                   -                        active
---------------------------------------------------------------------------
Total: 5

Імена провайдерів автентифікації є глобальними, тому наявність двох провайдерів з однаковим ім'ям не підтримується. Якщо немає інших невирішених умов, які могли б завадити операції з'єднання, повторне приєднання домену вирішує проблему.

Якщо є вимога приєднатися до одного й того ж провайдера домену AD з окремими обліковими записами машини, слід використовувати функцію мультиінстанціювання. Це детально розглянуто в розділі «Постачальники автентифікації, специфічні для зони» в Керівництві адміністрування OneFS. Пам'ятайте, що провайдера AD, який знову приєднався, потрібно додати до будь-яких зон доступу, де він був раніше,

щоб відновити доступ.Дивіться статтю PowerScale OneFS Info Hubs для документації вашої версії OneFS.