18 мар. 2011 г.

FAQ по интеграции с Microsoft Active Directory.


Short introduction. In this article we'll collect answers and solutions to common problems, you can stumble upon, when performing integration of OIM and MS Active Directory.

1. Q: Я пытаюсь настроить взаимодействие OIM 11g (или 9.X) и AD через SSL (например, для возможности смены пароля). Я следую действиям, описанным в работе для 9.Х (текст здесь), экспортировал CA сертификат, загрузил его в CACERTS на JVM, на которой функционирует OIM, но при попытке установить соединение, получаю ошибку: "com.thortech.xl.exception.ConnectionException: Simple bind failed: host:636"




A: Данная ошибка означает, что коннектору не удалось установить соединение по защищенному протоколу с AD и может возникнуть по ряду причин, которые довольно сложно отследить. Наиболее распространенные причины следующие.

- не импортирован CA сертификат  в хранилище JVM ($JAVA_HOME/jre/lib/security/cacerts, пароль по умолчанию – "changeit"), или импортирован в хранилище одной JVM, а сервер запускается на другой; в это хранилище сертификат нужно добавлять как для OIM 9.X, так и для OIM 11g;
- не импортирован CA сертификат в хранилище Weblogic ($WLS_HOME/server/lib/DemoTrust.jks, пароль по умолчанию – "DemoTrustKeyStorePassPhrase"), это нужно только если вы используете OIM 11g; в случае, если у вас настроено собственное хранилище сертификатов для Weblogic'а, необходимо импортировать сертификат и туда;
- просрочен CA сертификат, это легко посмотреть через Certificate Authority (если используются средства Microsoft), просмотрев свойства корневого сертификата;
- просрочен сертификат AD, это легко посмотреть через Certificate Authority (если используются средства Microsoft), просмотрев свойства сертификатов в папке Issued;
- у вас не настроен SSL на AD, это легко проверить, выполнив команду "telnet host 636", или "netstat –a" на машине с AD, проверив, слушается ли порт 636 / LDAPS, если порт сервером не прослушивается, необходимо выполнить действия в соответствии с документацией к коннектору;
- неправильный тип CA, для корректной интеграции требуется Enterprise Root CA, вариант со Standalone CA работать не будет.

2. TBC....

3 комментария:

  1. Олег, приветствую. Здесь возможен еще один вариант: в setDomainEnv.sh присутствует явное задание пути к хранилищу: "-Djavax.net.ssl.trustStore=${WL_HOME}/server/lib/DemoTrust.jks". Соответственно, если используется другое trust-хранилище (а для промышленной версии наиболее корректным будет создание именно такого пустого хранилища с последующим наполнением его "нужными" CA-сертификатами), java-машина его не увидит (несмотря на прописанные keystores в консоли WLS) и LDAPS к AD работать не будет. Т.е., параметр -Djavax.net.ssl.trustStore в файле $DOMAIN_HOME/bin/setDomainEnv.sh нужно будет соответствующим образом поправить

    ОтветитьУдалить
  2. Еще немножко по поводу "неправильного типа CA": подозреваю, что при некотором "подшаманивании" конфигурации работоспособными окажутся оба варианта. Во всяком случае двухуровневый CA на базе OpenSSL под FreeBSD выпускает вполне себе работоспособные сертификаты контроллера домена :)

    ОтветитьУдалить
  3. Алексей, спасибо за важное дополнение!

    п.с. уверен, что можно "допилить" любой вариант, впрочем, для этого уже требуется изучение предмета куда более детальное - в большинстве же случаев удовлетворяются результатом как можно быстрее ;)

    ОтветитьУдалить