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....
Олег, приветствую. Здесь возможен еще один вариант: в 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 нужно будет соответствующим образом поправить
ReplyDeleteЕще немножко по поводу "неправильного типа CA": подозреваю, что при некотором "подшаманивании" конфигурации работоспособными окажутся оба варианта. Во всяком случае двухуровневый CA на базе OpenSSL под FreeBSD выпускает вполне себе работоспособные сертификаты контроллера домена :)
ReplyDeleteАлексей, спасибо за важное дополнение!
ReplyDeleteп.с. уверен, что можно "допилить" любой вариант, впрочем, для этого уже требуется изучение предмета куда более детальное - в большинстве же случаев удовлетворяются результатом как можно быстрее ;)