Hello,
working on implementation of new Intranet solution in large environment based on Apache (that should replace current IIS).

Just got a doc with a planning from solution vendor.
My current question is about user authentication. I am network admin.
The vendor mentions in his doc that it's possible to use AD authentication if the IT dep can link a user name and domain name for the user in the CSV of importation of employee's record (???). I guess it will be just a headache..

Can somebody clarify the point above?

Then I made a Google search and found the solution here on Linuxsecrets:

https://www.linuxsecrets.com/entry/9...tion-in-apache

I quickly read it and it looks that just configuring LDAP module on Linux with the right DOMAIN NAME will do the trick?
Did I understand it correctly?
Thanks!

Nobody can clarify the above point for you because you give no useful information. You do not tell us if the authentication is done at the Apache level or at the application level. Check with your vendor.

Again nobody can tell you because, as I said above, we don't know if your application is using an Apache module or doing the authentication internally.

Using LDAP / AD authentication with Apache is highly possible although I'm assuming that if your vendors application makes use of employee records and you have multiple users then you'll have to at some stage do the actual mapping to prevent users seeing others data.

First, thanks for the answer...
I guess somebody who actually uses Apache in AD environment can answer with real life details. As mentioned there are many posts on Internet that mention only utilization of LDAP module configuration for authentication in Apache using AD login. Didn't see any that mention some CSV file containing AD user names. That is why I asked. One thing is clear that the vendor have very limited knowledge on AD and Linux coexistence and offers some primitive ideas (just my thinking).
The CSV should be managed on daily bases (users come and go). So I guess it is not an appropriate solution.

> You do not tell us if the authentication is done at the Apache level or at the application level.

The idea is that any AD user logged in to AD should be able to open home page of the INTRANET site without any further credentials tapping. Then the users will have access only to their permitted areas on website.

As an alternative the vendor mentions local user DB. This just confirms that authentication in Apache should happen in Apache level and not App's level.

CPanel will be used by managers for adding user rights to website resources.

Thanks again.

Yeah, maybe somebody who with real life experience. I guess integrating AD with Apache, Nagios, Jira, Confluence, Splunk, etc. doesn't count as "real life" enough for you.

Ok, things get a little clearer. The fact that "users will have access only to their permitted areas" indicates that some form of mapping or permissioning needs to take place between the AD user and the website user. For example, when integrating LDAP/AD authentication with Splunk permissioning is done by mapping an AD group to an internal application role but it's Splunk itself that handles the entry of username/password (unless you implement SSO). The same thing may apply in this case.

With Nagios, authentication is done by Apache and then there are application settings that handle the mapping of AD groups to permissions.

I'd provide you the examples I use with Nagios and AD but I'm sure you'd rather someone with "real life" experience will come along and help you.

Just look at this beautiful explanation...

http://fm4dd.com/security/apache-lda...-directory.htm

I just expected that somebody uses such implementation in large prod environment and elaborate a bit the experience.

TenTenths,
thanks for sharing... didn't have any intention to say something not polite (by "real life" ).

There is a lot of messy stuff around, but it's upper management that trying to push this specific vendor.
I just suggested to them to ask for the DEMO that will be clear to decision makers and obviously for the technical stuff.