Устранение неполадок в GCDS

В этой статье приведены советы по устранению неполадок, возникающих при настройке приложения Google Cloud Directory Sync (GCDS).

Анализатор журналов

Этот инструмент выявляет большинство неполадок практически сразу.

Загрузите журналы трассировки (в виде несжатых файлов или ZIP-архива) в Анализатор журналов, входящий в Набор инструментов администратора Google.
Чтобы выполнить расширенный анализ журналов, загрузите несжатые файлы в Анализатор журналов 2.

Подробнее о том, как включить запись в журнал уровня Trace…

Настройка и конфигурация

Развернуть раздел | Свернуть все и перейти к началу

Как устранить проблему с помощью Диспетчера конфигураций

Если при синхронизации возникают сбои, проверьте правильность настроек конфигурации.

В Диспетчере конфигураций откройте XML-файл, используемый для настройки синхронизации.
Чтобы проверить подключение к серверу LDAP, на странице LDAP Connections (Соединения LDAP) нажмите Test Connections (Протестировать соединения).
Чтобы проверить отправку тестовых уведомлений, выберите Test Notification (Протестировать уведомления) на странице Notifications (Уведомления).
Чтобы убедиться, что вы заполнили все необходимые поля, а синхронизация работает корректно, на странице Sync (Синхронизация) нажмите Simulate Sync (Моделировать синхронизацию).

Как включить ведение подробных HTTP-журналов для запросов к API?

В редких случаях специалисты службы поддержки Google Cloud могут попросить вас включить полную детализацию HTTP-журналов в дополнение к детализации на уровне Trace (Трассировка) для журналов GCDS. Это поможет узнать, какие именно запросы к API отправило приложение GCDS и какие ответы оно получило от API Google.

Обратите внимание! В подробных HTTP-журналах может содержаться конфиденциальная информация. Прежде чем отправлять их в службу поддержки, удалите эту информацию (например, данные в полях refresh_token и access_token).

Чтобы включить ведение подробных HTTP-журналов, выполните следующие действия:

С помощью команды sync-cmd или Диспетчера конфигураций убедитесь, что приложение GCDS не запущено.
Перейдите в папку, где установлено приложение GCDS.
Измените файл jre/lib/logging.properties.
Добавьте в конец файла следующие строки:
java.util.logging.FileHandler.pattern = %h/gcdshttp%u.%g.log java.util.logging.FileHandler.limit = 5000000 java.util.logging.FileHandler.count = 100 java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter handlers = java.util.logging.FileHandler com.google.api.client.http.level = CONFIG com.google.gdata.client.http.HttpGDataRequest.level = ALL sun.net.www.protocol.http.HttpURLConnection.level = ALL
Сохраните файл.
Запустите синхронизацию GCDS с уровнем детализации журнала Trace (Трассировка).
Файлы журнала с именем gcdshttp*.log создаются в каталоге homedir (Linux) или папке профиля (Microsoft Windows). Файлы могут быть достаточно большими, поэтому добавьте их в один архив.
Чтобы предотвратить создание больших файлов журнала в будущем, удалите строки, добавленные на шаге 4.

Затем отправьте в службу поддержки следующие файлы:

используемый XML-файл;
журналы отслеживания, созданные во время последней синхронизации;
файлы gcdshttp*.log, сгенерированные во время синхронизации.

С помощью этих файлов служба поддержки сможет выяснить, какую информацию приложение GCDS получило от Directory API и что оно отправило в ответ.

Размер записываемых запросов и ответов ограничен 16 КБ. Если вам встретится запись в журнале, которая усечена в связи с этим ограничением, используйте Fiddler (описание можно найти ниже).

Примечание. Если вы хотите использовать для отладки GCDS прокси-сервер, например Fiddler, необходимо обновить файлы .vmoptions таким образом, чтобы приложение GCDS использовало хранилище доверенных сертификатов Windows, а также отключить проверки CRL. Затем установите Fiddler в качестве прокси-сервера для GCDS (обычно для этого используются IP-адрес 127.0.0.1 и порт 8888), и он будет вести журналы подключения. Хранилище доверенных сертификатов Windows недоступно пользователям GCDS на Linux. В таком случае необходимо импортировать корневой сертификат Fiddler в базу доверенных сертификатов Java в GCDS. Подробнее об импорте сертификата сервера…

Как открыть XML-файл, сохраненный на другом компьютере или в другом профиле пользователя?

Инструкции приведены в статье Как работать с файлами конфигурации.

Как экспортировать данные из каталога LDAP?

Если данные LDAP в журналах GCDS уровня Trace (Трассировка) не соответствуют ожидаемой информации на сервере LDAP (например, отсутствует пользователь или у атрибута неправильное значение), экспортируйте данные из каталога LDAP в формате LDIF. Специалисты службы поддержки могут сравнить эти данные с данными LDAP в журналах GCDS.

При экспорте данных используйте инструмент запросов LDAP, например ldapsearch (Linux) или ldifde (Windows) и воссоздайте условия, в которых работает GCDS:

используйте те же настройки подключения, что и для GCDS;
запустите инструмент запросов на том же компьютере, на котором работает GCDS;
укажите то же имя пользователя, которое используется GCDS для доступа к LDAP.

Пример

В журналах GCDS нет атрибута mail пользователей и указано следующее правило поиска GCDS:

Base DN (Базовое уникальное имя): ou=Ireland,dc=altostrat,dc=com
Scope (Область действия): Subtree
Search filter (Фильтр поиска): (&(objectCategory=person)(objectClass=user))
Server (Сервер): dc01.altostrat.com
Port (Порт): 636
Protocol (Протокол): LDAP+SSL
Authentication user DN (Уникальное имя пользователя для аутентификации): cn=GCDS,ou=Users,dc=altostrat,dc=com

Используйте следующие команды:

Linux: ldapsearch -v -b "ou=Ireland,dc=altostrat,dc=com" -s sub -h dc01.altostrat.com -p 636 -x -Z -D "cn=GCDS,ou=Users,dc=altostrat,dc=com" "(&(objectCategory=person)(objectClass=user))" mail givenname uniqueidentifier sn > out.ldif (возможно, вам понадобится изменить команду в зависимости от системы).
Windows: ldifde -f out.ldif -s dc01.altostrat.com -v -t 636 -d "ou=Ireland,dc=altostrat,dc=com" -r "(&(objectCategory=person)(objectClass=user))" -p SubTree -l mail,givenname,uniqueidentifier,sn -a "cn=GCDS,ou=Users,dc=altostrat,dc=com" PASSWORD (замените PASSWORD паролем пользователя LDAP, заданным в GCDS).

Если в выходных данных (out.ldif) не будет атрибута mail для затронутого пользователя, то проблема в инфраструктуре LDAP. Она может быть связана с разрешениями пользователя, которого вы выбрали для доступа к LDAP (например, и в OpenLDAP, и в Active Directory разрешено задавать разрешения на уровне атрибутов). Возможно, атрибут не продублирован в глобальном каталоге, если вы используете порт глобального каталога, например 3268 или 3269.

Если в выходных данных есть атрибут mail для затронутого пользователя, отправьте в службу поддержки Google Workspace следующие сведения:

файл out.ldif;
скриншот командной строки или окна терминала, где вы выполнили команду (не забудьте сначала скрыть пароль);
журнал GCDS уровня Trace.

Синхронизация и ее моделирование

Развернуть раздел | Свернуть все и перейти к началу

Нужен ли сервер уведомлений, чтобы моделировать синхронизацию?

Вам потребуется сервер, который может отправлять сообщения. При запуске GCDS на почтовом сервере используйте для него IP-адрес 127.0.0.1. В других случаях уточните данные у администратора почтового сервиса.

Почему GCDS не выполняет синхронизацию при ее запуске с помощью командной строки?

Если вы запускаете синхронизацию с помощью командной строки, а она не начинается, проверьте, использовали ли вы аргумент -o или --oneinstance.

При использовании одного из этих аргументов GCDS создает файл LOCK (.lock), связанный с XML-файлом конфигурации. Если на том же сервере будет обнаружен другой файл LOCK, GCDS не будет выполнять синхронизацию, чтобы не допустить одновременной работы нескольких экземпляров GCDS.

Если ни один другой экземпляр GCDS не работает, проверьте наличие другого файла LOCK на сервере. Удалите файл вручную и снова попробуйте запустить синхронизацию.

Синхронизация не была завершена. Может ли проблема быть связана с API?

Если синхронизация не была завершена, например не были синхронизированы все участники группы, возможно, возникла неисправность в Directory API. Чтобы узнать, действительно ли причина связана с API, а не с GCDS, вызовите Directory API вручную и изучите результаты. Вызвать API вручную можно двумя способами.

Вариант 1. Используйте документацию по API

Перейдите на страницу обзора документации по Admin SDK API.
В левой части страницы нажмите Directory API, а затем в списке REST Resources выберите ресурс REST, к которому хотите отправить запрос.
Справа выберите способ и нажмите Попробовать.
Если на странице документации по API нет кнопки Попробовать, следуйте инструкциям в разделе "Вариант 2. Используйте OAuth 2.0 Playground".
Укажите учетные данные администратора, которые вы использовали при авторизации GCDS.
Дополнительные сведения можно найти в разделе Как настроить домен Google.
Изучите информацию, чтобы убедиться, что от API получен правильный ответ.

Вариант 2. Используйте OAuth 2.0 Playground

Откройте OAuth 2.0 Playground.
Выберите один из вариантов ниже.
- Выберите область действия из списка.
- Скопируйте область действия из списка Области действия авторизации на странице документации по API, а затем вставьте в поле Укажите собственные области действия.
Нажмите Авторизовать API.
Укажите учетные данные администратора, которые вы использовали при авторизации GCDS.
Дополнительные сведения можно найти в разделе Как настроить домен Google.
Нажмите кнопку Обменять код авторизации на токены.
Если процесс будет выполнен успешно, вы будете направлены на Шаг 3. Настройка запроса к API.
Укажите требуемые сведения.
Примечание. Большинство информации можно найти на веб-странице документации по API.
Нажмите Отправить запрос.
Изучите информацию, чтобы убедиться, что от API получен правильный ответ.

Ошибки

Развернуть раздел | Свернуть все и перейти к началу

Что делать, если возникают конфликты или GCDS выдает сообщения об ошибках EntityDoesNotExist (Объект не существует) и EntityExists (Объект существует)?

В XML-файле конфигурации включите параметр useDynamicMaxCacheLifetime. Он разрешает кеширование данных максимум за восемь дней, благодаря чему кеш очищается чаще и информация удаляется небольшими порциями. Это позволяет избежать хранения устаревших данных и конфликтов с новой информацией. Параметр useDynamicMaxCacheLifetime автоматически включается в конфигурациях, созданных в GCDS 3.2.1 и более поздних версий.

Примечание. Такие ошибки обычно возникают, когда вы вносите изменения напрямую через домен Google. При работе с GCDS этого нужно избегать. Редактируйте данные о пользователях, группах и других объектах в каталоге LDAP, а затем с помощью GCDS синхронизируйте изменения с доменом Google.

Как исправить ошибки, связанные с памятью?

Если возникают ошибки, связанные с объемом памяти, увеличьте размер динамически распределяемой памяти, доступный виртуальной машине Java. Для этого отредактируйте файлы sync-cmd.vmoptions и config-manager.vmoptions в папке, где установлено приложение GCDS. Записи выглядят так:

-Xmx1000m (максимальный объем динамически распределяемой памяти);
-Xms64m (минимальный объем динамически распределяемой памяти).

Чтобы распространить изменения как на команду sync-cmd, так и на Диспетчер конфигураций, отредактируйте оба файла (sync-cmd.vmoptions и config-manager.vmoptions).

Чтобы увеличить объем памяти, измените число в параметре -Xmx. Буква m после него означает мегабайты. Оптимальное значение этой величины зависит от количества доступной памяти на сервере GCDS и от ее объема, необходимого для синхронизации. Для подбора наилучшего варианта может потребоваться изменить это число несколько раз. Подробнее об оптимальном объеме памяти для работы GCDS…

Почему GCDS возвращает ошибку даже после отключения кеширования?

Возможно, проблема заключается в неправильной конфигурации правила исключения. Кеширование GCDS может скрыть ее.

Данные сервиса Google (например, Google Workspace или Cloud Identity) хранятся в кеше GCDS до восьми дней, однако они могут удаляться чаще в зависимости от их объема. Если кеш не очищен, может пройти до восьми дней, прежде чем изменения вступят в силу.

Например, вы синхронизируете данные каталога LDAP и создаете группу в сервисе Google (это может быть Google Workspace или Cloud Identity). Затем вы задаете правило, чтобы исключить ее из последующих синхронизаций. Оно настроено неправильно и не сработает. Однако при следующей синхронизации будут запрошены данные из кеша, и группа останется в сервисе Google. При новой синхронизации после очистки кеша группа будет удалена из сервиса Google из-за неправильной конфигурации.

Чтобы очистить кеш вручную, выполните следующие действия:

Запустите синхронизацию из Диспетчера конфигураций и выберите очистку кеша.
Запустите синхронизацию с помощью командной строки, используя аргумент -f, чтобы принудительно очистить кеш.
Отредактируйте файл конфигурации XML, установив для параметра maxCacheLifetime значение "0".

Внимание! Принудительная очистка кеша может значительно увеличить время синхронизации.

Пользователи и группы

Развернуть раздел | Свернуть все и перейти к началу

Почему GCDS пытается создать аккаунты пользователей Google, которые уже существуют?

Если возникает ошибка 409: такой объект уже существует, GCDS пытается создать аккаунты пользователей Google, которые уже существуют. Если при последующих синхронизациях ошибка не появится, скорее всего, кеш GCDS был устаревшим и ошибку можно игнорировать.

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

Правило исключения пользователей Google слишком широкое – под него подпадают некоторые пользователи, которые также есть в каталоге LDAP.
Запрос слишком узкий – он не соответствует некоторым пользователям Google, которые также есть в каталоге LDAP.

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

Чтобы устранить эту проблему, измените правило исключения или поисковый запрос. Если же вы хотите, чтобы GCDS полностью игнорировал пользователей в каталоге LDAP, измените правило поиска пользователей LDAP или создайте правило исключения пользователей LDAP. Подробнее о том, как использовать правила исключения и запросы, чтобы не синхронизировать определенные данные…

Почему при синхронизации некоторые пользователи оказываются не включены в группы?

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

Чтобы синхронизировать участников группы только на основе результатов поиска пользователей, удалите параметр INDEPENDENT_GROUP_SYNC из XML-файла конфигурации. GCDS:

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

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

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

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

Назначьте в качестве атрибута названия группы другой атрибут LDAP, в котором указывается полный адрес электронной почты (например, mail).
В разделе Google Domain Settings (Настройки домена Google) включите параметр Replace domain names in LDAP email addresses (Заменять доменные имена в адресах электронной почты LDAP). В этом случае атрибут названия группы будет соответствовать данным в сервисах Google.
Добавьте к названию группы доменное имя. Для этого укажите суффикс названия группы в правиле поиска группы.

Группы на сервере Active Directory, в которых больше 1500 участников, синхронизируются некорректно

Откройте раздел LDAP Configuration (Конфигурация LDAP) и убедитесь, что в поле для типа сервера указано значение MS Active Directory.

Как использовать параметр "Заменять имена доменов в адресах электронной почты LDAP"?

Этот параметр, задаваемый в XML-файле в виде строки SUPPRESS_DOMAIN, используется, если адреса электронной почты в каталоге LDAP находятся не в вашем домене Google. Если этот параметр включен, GCDS отсекает у адресов доменную часть.

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

Например, если параметр Replace domain names in LDAP email addresses (Заменять доменные имена в адресах электронной почты LDAP) отключен, то при создании правила исключения с точным соответствием нужно указывать полный адрес: luka@example.com. Если вы установили флажок Replace domain names in LDAP email addresses (Заменять доменные имена в адресах электронной почты LDAP), используйте luka. При сравнении с образцом luka@example.com соответствие не будет установлено, поскольку вторая часть адреса (@example.com) была удалена до сравнения.

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

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

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

Почему запрос LDAP дал неожиданные результаты?

Результаты запросов LDAP зависят от настроек Диспетчера конфигураций и сервера LDAP. Если правило поиска LDAP возвращает неожиданный результат, используйте приведенные ниже советы по устранению неполадок. Убедитесь, что:

Запрос LDAP указан правильно в Диспетчере конфигураций. При настройке правила поиска нажмите Test LDAP query (Проверить запрос LDAP), чтобы проверить его. Подробнее об использовании правил поиска LDAP для синхронизации данных…
Нет противоречий между несколькими запросами. Проверьте, не настроили ли вы правило поиска или исключения, которое меняет результат запроса.
У авторизованного пользователя сервера LDAP есть необходимые разрешения. Убедитесь, что администратор, который выполняет аутентификацию на сервере LDAP, может использовать на нем командную строку. Попробуйте выполнить запрос на сервере LDAP и проверьте результаты.

Ошибка "Не удалось создать группу"

В журналах GCDS вы можете увидеть сообщение об ошибке Group ... could not be created. Message: Not Authorized to access this resource/api. (Не удалось создать группу "…". Сообщение: нет права на доступ к этому ресурсу/API.)

Чтобы устранить неполадку, убедитесь, что атрибут Active Directory (AD), который содержит домен адресов электронной почты пользователя и группы, соответствует домену, используемому для аккаунта суперадминистратора.

Контакты и календари

Развернуть раздел | Свернуть все и перейти к началу

Почему после синхронизации с использованием GCDS в каталоге домена появились повторяющиеся контакты?

Обычно эта проблема возникает, если при синхронизации общих контактов правила поиска заданы некорректно.

С помощью GCDS можно синхронизировать объекты двух типов:

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

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

Почему некоторые пользователи не видят адрес своего основного места работы в Google Календаре?

В некоторых случаях при планировании мероприятий в Google Календаре адрес основного места работы пользователя не показывается.

Чтобы этого не происходило, установите для атрибутов типа местоположения и области значение desk.

Правила

Развернуть раздел | Свернуть все и перейти к началу

Почему правило поиска не выдает результатов?

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

Область действия правила. Возможно, для нее нужно задать значение Sub-tree.
Корректность правила.
Что используемые атрибуты существуют и являются видимыми.

Запрос LDAP. Убедитесь, что в запросе на сервере LDAP используется то же имя пользователя, которое настроено в GCDS.

Подробнее об использовании правил поиска LDAP для синхронизации данных…

Почему при создании правила исключения отсутствует кнопка "ОК"?

Возможно, вы используете слишком крупный шрифт. В диалоговом окне большие или очень большие шрифты отображаются некорректно. Измените размер шрифта или отредактируйте сам XML-файл.

Статьи по теме

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

_{Google, Google Workspace, а также другие связанные знаки и логотипы являются товарными знаками компании Google LLC. Все другие названия компаний и продуктов являются товарными знаками соответствующих компаний.}

Эта информация оказалась полезной?

Как можно улучшить эту статью?