Известные проблемы

Известные проблемы#

В процессе миграции Astra Automation на версию 2.0 были выявлены ограничения миграции данных. В связи с этим обновление платформы рекомендуется выполнять только после ознакомления с приведенными ниже особенностями и с учетом планируемых исправлений.

Список известных проблем:

Неполный перенос учетных записей пользователей внутри организаций#

После миграции часть пользователей может потерять членство в организациях, в которых они состояли до миграции. Проблема наблюдается преимущественно в организациях с большим количеством пользователей.

Примечание

Исправление запланировано в релизе Astra Automation 2.0-upd1.

Ошибочное добавление пользователей в чужие организации#

После миграции возможно появление пользователей в организациях, в которых они не состояли до миграции.

В ходе миграции используется сопоставление (mapping) идентификаторов учетных записей пользователей между компонентами Automation Controller версии 1.2 и Gateway версии 2.0. Возможна ситуация, когда сопоставление может выполняться некорректно, что приводит к добавлению пользователей в организации, в которых они ранее не состояли.

Примечание

Исправление запланировано в релизе Astra Automation 2.0-upd1.

Некорректная обработка организационных ролей#

Средства миграции обрабатывают все существующие организационные роли из Automation Controller версии 1.2, включая роли с гранулярными правами, и сопоставляют их с ролевой моделью Gateway версии 2.0. Возможна ситуация, когда эта проверка приводит к добавлению пользователей в организации, в которых они ранее не состояли.

Примечание

Исправление запланировано в релизе Astra Automation 2.0-upd1.

Дублирование учетных записей SSO#

Automation Controller и Private Automation Hub версии 1.2 используют независимые источники аутентификации. При миграции их учетные записи переносятся в Gateway 2.0 без автоматического объединения.

В результате в системе создаются две отдельные учетные записи, принадлежащие одному пользователю, каждая из которых связана со своим аутентификатором и набором прав.

Типичная ситуация дублирования выглядит следующим образом:

  • учетная запись вида username@astralinux.ru – перенесена из Automation Controller;

  • учетная запись вида username – перенесена из Private Automation Hub.

Обе учетные записи принадлежат одному и тому же пользователю, но связаны с разными аутентификаторами и существуют в системе как независимые объекты.

Для устранения дубликатов требуется ручное объединение учетных записей. Следуйте приведенной ниже инструкции.

Шаг 1. Получение списка учетных записей#

На первом этапе необходимо получить полный список учетных записей пользователей, чтобы выявить дублированные учетные записи. Для этого выполните следующий запрос:

curl -X GET "https://<ip_gateway>/api/gateway/v1/users/?page=1&page_size=1000" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     --insecure

Здесь:

  • <ip_gateway> – IP-адрес шлюза платформы;

  • page – номер страницы (начиная с 1) со списком учетных записей пользователей;

  • page_size – количество записей на странице (не более 1000).

Пример ожидаемого результата
{
  "count": 150,
  "next": "https://<ip_gateway>/api/gateway/v1/users/?page=2&page_size=1000",
  "previous": null,
  "results": [
    {
      "id": 42,
      "username": "testuser@astralinux.ru",
      "email": "testuser@example.com",
      "authenticators": [101],
      "last_login": "2025-01-15T10:30:00Z"
    },
    {
      "id": 43,
      "username": "testuser",
      "email": "testuser@example.com",
      "authenticators": [102],
      "last_login": "2025-01-14T09:20:00Z"
    }
  ]
}

Если в ответе поле next содержит URL, необходимо выполнить запрос для следующей страницы. Повторяйте запросы до тех пор, пока next не станет null.

Сохраните полученные ответы в любом удобном формате для дальнейшего анализа.

Шаг 2. Определение дублированных учетных записей#

На основании полученного списка необходимо определить пары дублированные учетные записи.

Учетные записи считаются дубликатами, если выполняются все условия:

  • один пользователь имеет название учетной записи вида username@astralinux.ru, второй – username;

  • у учетных записей совпадает значение поля email;

  • нормализованное название учетной записи пользователя (без доменного суффикса) совпадает.

Пример дублированной пары:

  • Пользователь 1:

    • название учетной записи: testuser@astralinux.ru;

    • ID: 42;

    • email: testuser@astralinux.ru.

  • Пользователь 2:

    • название учетной записи: testuser;

    • ID: 43;

    • email: testuser@astralinux.ru.

Для дальнейших шагов используются следующие термины:

  • Целевая учетная запись пользователя (Target User) – учетная запись с доменным суффиксом, которая сохраняется. В приведенном выше примере – пользователь с ID 42.

  • Исходная учетная запись пользователь (Source User) – учетная запись без доменного суффикса, которая будет удалена. В приведенном выше примере – пользователь с ID 43.

Шаг 3. Получение связанных аутентификаторов#

Для каждой учетной записи необходимо определить, с какими аутентификаторами она связана. Это выполняется через ресурс authenticator_users.

Запрос для исходной учетной записи пользователя (в примере выше – учетная запись с ID 43) выглядит следующим образом:

curl -X GET "https://<ip_gateway>/api/gateway/v1/authenticator_users/?user=43" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     --insecure
Пример ожидаемого результата
{
  "results": [
    {
      "id": 201,
      "user": 43,
      "uid": "testuser",
      "summary_fields": {
        "provider": {
          "id": 102,
          "name": "Hub Authenticator"
        }
      }
    }
  ]
}

Запрос для целевой учетной записи пользователя (в примере выше – учетная запись с ID 42) выглядит следующим образом:

curl -X GET "https://<ip_gateway>/api/gateway/v1/authenticator_users/?user=42" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     --insecure
Пример ожидаемого результата
{
  "results": [
    {
      "id": 200,
      "user": 42,
      "uid": "testuser@astralinux.ru",
      "summary_fields": {
        "provider": {
          "id": 101,
          "name": "Controller Authenticator"
        }
      }
    }
  ]
}

Для каждой учетной записи сохраните в любом удобном формате следующие данные:

  • значение поля authenticator_user.id (в приведенном выше примере – 201 для исходной учетной записи пользователя и 200 – для целевой);

  • идентификатор аутентификатора summary_fields.provider.id (в приведенном выше примере – 102 для исходной учетной записи пользователя и 101 – для целевой).

Эти данные потребуются для выполнения операции объединения.

Шаг 4. Объединение учетных записей#

Следующим шагом необходимо объединить учетные записи путем переноса аутентификатора исходной учетной записи пользователя к целевой.

В результате операции:

  • целевая учетная запись пользователя получает дополнительный аутентификатор;

  • исходная учетная запись пользователя теряет связь с аутентификатором и может быть удалена;

  • членство в группах и организациях сохраняется.

Пример запроса:

curl -X POST "https://<ip_gateway>/api/gateway/v1/authenticator_users/<authenticator_user_id>/move/" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     -H "Content-Type: application/json" \
     --insecure \
     -d '{
       "new_authenticator": "102",
       "merge_with_user": "42",
       "merge_accounts_with_same_uid": false,
       "remove_other_authenticators": true,
       "keep_memberships": true
     }'

Здесь:

  • <authenticator_user_id> – идентификатор объекта authenticator_user, связанного с исходной учетной записью пользователя и подлежащая переносу;

  • new_authenticator – идентификатор аутентификатора, к которому будет привязан переносимый authenticator_user;

  • merge_with_user – идентификатор целевой учетной записи пользователя, с которым выполняется объединение;

  • merge_accounts_with_same_uid – опция автоматического объединения учетных записей с совпадающим UID. В данном сценарии должно быть установлено значение false (не объединять автоматически).

  • remove_other_authenticators – опция удаления остальных аутентификаторов исходной учетной записи пользователя после переноса.

  • keep_memberships – опция сохранения членства в группах и организациях при выполнении объединения.

После успешного выполнения запроса ожидается следующий результат:

  • объект authenticator_user с указанным идентификатором перенесен и привязан к целевой учетной записи пользователя;

  • исходная учетная запись пользователя автоматически удалена (если после переноса у нее не осталось связанных аутентификаторов);

  • все группы, роли и права доступа исходной учетной записи пользователя сохранены и стали доступны целевой учетной записи пользователя.

Шаг 5. Удаление исходной учетной записи#

Если после объединения исходная учетная запись пользователя не была удалена автоматически, ее можно удалить вручную. Для этого выполните следующий запрос:

curl -X DELETE "https://<ip_gateway>/api/gateway/v1/users/<id_source_user>/" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     --insecure

Здесь <id_source_user> – идентификатор исходной учетной записи пользователя.

Ожидаемые коды ответа:

  • 204 No Content – учетная запись пользователя удалена в результате выполненного запроса;

  • 404 Not Found – учетная запись пользователя не существует (была удален автоматически при объединении).

Шаг 6. Проверка результата#

Убедитесь, что объединение выполнено корректно, выполнив следующие шаги:

  1. Проверьте наличие целевой учетной записи пользователя:

    curl -X GET "https://<ip_gateway>/api/gateway/v1/users/42/" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     --insecure

  2. Проверьте, что у нее присутствуют все необходимые аутентификаторы:

    curl -X GET "https://<ip_gateway>/api/gateway/v1/authenticator_users/?user=42" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     --insecure
    Пример ожидаемого результата
    {
  "results": [
    {
      "id": 200,
      "user": 42,
      "summary_fields": {
        "provider": {
          "id": 101,
          "name": "Controller Authenticator"
        }
      }
    },
    {
      "id": 201,
      "user": 42,
      "summary_fields": {
        "provider": {
          "id": 102,
          "name": "Hub Authenticator"
        }
      }
    }
  ]
}

  3. Проверьте отсутствие исходной учетной записи пользователя:

    curl -X GET "https://<ip_gateway>/api/gateway/v1/users/<id_source_user>/" \
     -u "admin:admin" \
     -H "Accept: application/json" \
     --insecure

    Ожидаемый результат: 404 Not Found.