Я выполняю авторизацию LDAP вместе с аутентификацией Kerberos в httpd 2.4. Я получаю objectSID из ldap и обнаружил, что формат не читается.
Ссылаясь этот и этотиспользовали ReWriteMap для использования этого сценария для декодирования objectSid какRewriteRule .* - [E=SID:${SIDConvert:%{AUTHORIZE_objectSid}e}]. AUTHORIZE_objectSid - это то, что я получил из запроса LDAP. Но на выходе я получил S-1-0-0-0-0.
Я тестировал только сценарий со значением value, он дает правильный результат.
Ввод: AQUAAAAAAAUVAAAAkuA8d4B49TEjX2Nr4tAJAA ==
Выход: S-1-5-21-2000478354-838170752-1801674531-643298
Передано жестко закодированное значение из запроса ldap, результат верный.
Поэтому я предполагаю, что значение, полученное от ldap, не в ожидаемом формате. Как это узнать / отладить? Будем очень признательны за любые идеи / ссылки ..
У вас есть исходный код вашего скрипта карты ... Чтобы узнать, что происходит внутри скрипта, вы можете просто добавить вызовы регистрации (отправить в системный журнал или записать в какой-либо файл) о том, что он получает в качестве входных данных.
Однако я заметил, что все ваши примеры используют Base64. SID сохраняется и извлекается в необработанном двоичном формате, а не в Base64. (Base64 - это то, что ldapsearch выводит, когда обнаруживает значение, отличное от ASCII, но это не то, что хранится в фактическом атрибуте LDAP.)
Я подозреваю, что проблемы в следующем:
Ваш сценарий ожидает Base64, но ввод, поступающий от Apache, не закодирован в кодировке Base64, поэтому сценарий не понимает ввод.
Кроме того, двоичный SID может содержать байты NUL (0x00) внутри, и часто расширения, которые ожидают строку (например, переменные среды всегда являются строками), будут усекать ее до первого байта NUL и игнорировать остальные.
Лично я бы избегал иметь дело с необработанными SID - я бы создал группу Active Directory, содержащую авторизованных пользователей, и сопоставил бы, используя Require ldap-group.