@Sukru Haciyanli - maybe a little late, but hopeing that it might help.
I can provide you a config file for apache webserver 2.4.54 on SLES, which is quite similar to IBM IHS on Redhat
foo:/opt/IBM/httpd/conf # cat ldap.conf
# Load LDAP module
LoadModule ldap_module modules/mod_ldap.so
# Load LDAP AUTHNZ module
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
# Load Session, session cookie & session crypto module
LoadModule session_module modules/mod_session.so
LoadModule session_cookie_module modules/mod_session_cookie.so
LoadModule session_crypto_module modules/mod_session_crypto.so
# Load Form Login module
LoadModule auth_form_module modules/mod_auth_form.so
# Load Request module
LoadModule request_module modules/mod_request.so
# Set LDAP logout LVL
LDAPLibraryDebug 7
# If REMOTE_USER is set and user manually enters /login
# show some error.
RewriteEngine On
LogLevel alert rewrite:trace3
RewriteCond "%{LA-U:REMOTE_USER}" "(.+)"
RewriteRule "/login/" "/?username=%{LA-U:REMOTE_USER}" [R]
# Protect root of the webserver
<Location />
AuthType Form
AuthFormLoginRequiredLocation "/login/?r=nologin&redirect_to=%{REQUEST_URI}"
AuthName "amv-cmdip"
AuthFormProvider ldap
AuthLDAPURL "ldap://emea.foobar.net:3268/DC=foobar,DC=net?sAMAccountName?sub?(objectClass=*)"
AuthLDAPCompareAsUser on
LDAPReferrals off
AuthLDAPInitialBindAsUser on
AuthLDAPInitialBindPattern (.+) $1@EMEA
Session On
SessionCookieName amv-cmdip-session path=/
SessionCryptoPassphrase xxxx
Require valid-user
</Location>
<Location /login/do>
SetHandler form-login-handler
AuthFormLoginRequiredLocation "/login/?r=badcredentials&%{QUERY_STRING}"
</Location>
<Location /logout>
SetHandler form-logout-handler
AuthName "amv-cmdip"
AuthFormLogoutLocation "/login/logoff.html"
Session On
SessionCookieName amv-cmdip-session path=/
</Location>
# Unprotect /infra and /login path
<Location /infra/>
Require all granted
</Location>
<Location /login/>
Require all granted
</Location>
<LocationMatch /(prod|int|dev)/bi/v1/ext/MIFBackgroundImages>
Require all granted
</LocationMatch>
That said, we authenticate on OS level at the webserver using ApacheForms and from there hand over a REMOTE_USER environment variable with the UserID to the Application Server which reads from LDAP all the AD groups the user belongs to.
The user verification in Cognos flow is like this (somehow ... high level):
0.) Bind the LDAP
1.) Ask for GUID for the REMOTE_USERID
2.) Rebind with LDAP
3.) Ask for all Groups the GUID is in
4.) Then ask for each Group that was retrieved before.
So, if you have a lot of groups the users belong to, this can actually take QUITE a while (+10 seconds) depending on the number of groups and the involved servers.
We noted the following issues, that are not only related to AD only but to LDAP and/or IBM Cognos using the Authentication Source in general:
1.) LDAP connections are binded and closed in a suboptimal way (to phrase this politically correct ;-) )
2.) Asking for Group Details is not cached
3.) LDAP connections are not pooled
So, depending on your Authentication load, you might experience a performance degrade on your AD server for that reason. Apart from the "poor" performance (depending on the number of groups) on the end user side.
We actually went for implementing cJAP as provided in the Java-Samples. That is quite straight forward and gives us total control over connection pooling and caching.
So, step 2. to 4. (those are the most expensive queries to the LDAP) are only executed, if the user has not been seen before. The cache objects live for the up time of Cognos. Cache is cleared as Server is restarted.
For further issues, we can have screen sharing session.
Let me know, if that helped.
Edit:
* The LDAP port 389 used in the Cognos config is NOT encrypted, so passwords for binding are going clear text of the network
* Use port 636 (LDAPS) for encryption
* AND, if you have a multi-domain LDAP you might want to ask in other domains. Port 3268+3269 is for the global catalog as seen above. This works in Apache BUT Cognos does not support the global catalog out of the box ;-) You will receive a XML parsing error in DOM4j parser. So, multi-domain authentication in Apache = OK, in Cognos = NOK. This is where the cJAP comes in handy. We are also looking into multiple authentication providers/namespaces to reflect the multi-domain setup on the Webserver.
* We are still experimenting with the final setup and hope to finish by end of next week. I believe that we will end up using cJAP for pooling, caching AND multi-domain searches on the global catalog. cJAP is actually nothing more then a proxy, where we can control data coming in and going out to either side.
------------------------------
Ralf Roeber
https://linkedin.com/in/ralf-roeber/------------------------------
Original Message:
Sent: Wed October 05, 2022 05:25 PM
From: Sukru Haciyanli
Subject: Cognos - linux - active directory - sso
Dear all
Has anyone tried to configure Cognos Analytics which is installed on redhat linux (including ibm http server) and single sign on to MS active directory.
Do you have a step by step guideline?
Regards
Sukru
#CognosAnalyticswithWatson