I don't have anything to add to Paul's latest response, but wanted to clarify one item from the original post where you had a question that had not been answered. You said: "One item I noticed however was that there can be only one LDAP server, which means I cannot have both the company LDAP server for internal users and this possible Linux LDAP server for external ones. Is this correct?" It is true that you can only specify one LDAP server using the options provided, but in your scenario if you were to set up an LDAP server, that wouldn't be a problem. You are using Windows as your back-end system, so the default of Windows host authentication is used for authenticating users. As you mentioned, whether the user is a local defined user or an AD user, it doesn't matter: they will be successfully authenticated. This is because we use a Windows API for authentication. We do not talk to AD directly. With a default Window AD setup, the AD server being used for back-end authentication does not count as an LDAP server. Your internal users can stll be authenticated against AD with their Windows accounts, and you could set up an LDAP server to authenticate the external users. That is perfectly acceptable and not uncommon. Where this begins to have problems is your statement that adding "@DOMAIN" won't be acceptable. The authenticaiton system only authenticates an incoming user against a single provider. Without a domain qualifier, the system has no way to kow which provider the account is destined for, so it sends it to the default provider. That is typically "host" though it can be altered wuth the primaryproviderdomain option. Regardless, without a domain qualifier to determine where to authenticate a user in a system with multiple providers, the system will always send users to the default provider. Since the external users are purely web-based users, what I have seen done in the field, is for a domain to be added behind the scenes in the web app that the users are never aware of. They log in with just their user name, and before the username is sent off to the back-end for authentication, "@DOMAIN" is appended. With this, the authentication code will send the username and password to the correct provider for authentication. I am not a web app person, so I don't know where this is done, but I kow it has been done, so someone out there can probably explain the details. Of course, the internal users should not have this happen, and that may ruin this scheme. If the internal users are not using the externally presented web apps, this can work. If they are, you are back to a mix of users that cannot be distinguished. Maybe the external users are using a different deployment of the web apps?
... View more