First of all, I have poor experience on IIS, I'm more a linux/apache/nginx guy.

Now I have a proprietary app running on an old IIS (w2003, I know is out of support) which is currently authenticating against domainA using integrated windows authentication.

I need to make it authenticate against a completely separate w2003 AD, too. I can route between the two networks. This works all on internal networks.

The app currently maps each domainA user to its personal account & details, the same should happen for domainB users. Obviously I can't change the app in any way.

I guess I could set a trust between domainA and domainB, but if possible it would be best to avoid this. Long story.

I wonder if there could be other methods, eg: make IIS authenticate users also against a LDAP, and make domainB AD act as that LDAP. Or else. Anything that works could be interesting.

  • Sounds like you've got a bunch of technical debt coming due. The only real solution to that situation is to pay the bill and wipe out the debt. Fortunately, there's nothing quite like a hard technical limitation to convince management to pay up, and that's what I'd focus on, at least. Apr 20, 2016 at 22:02
  • Sorry, I'm not a native english speaker, can you elaborate more on "technical debt coming due", "pay the bill and wipe out the debt" just to make me sure to understand?
    – m.ardito
    Apr 21, 2016 at 11:56
  • Technical debt is a metaphor referring to the eventual consequences of any system design. The debt can be thought of as work that needs to be done before a the job can be considered complete or proper. If the debt is not repaid, it will keep on accumulating interest, making it hard to implement changes later on. By not keeping this application current and maintained, your employers have accrued a large amount of debt in terms of time and resources - it would probably be cheaper to replace or update it than create a fix for the current problem. Apr 21, 2016 at 13:54

1 Answer 1


Without a trust, you're almost definitely out of luck unless the app explicitly supports adding a second domain identity source (that would need to involve providing credentials for the second domain).

Even with a trust, you might still be out of luck depending on how well the app was written and whether it made any assumptions about only ever existing in a single-domain forest. A lot of app authors are just short sighted when it comes to that sort of thing.

If it magically does work with a trust, you might still ultimately run into edge cases where things break randomly. Like what happens if two users from the different domains happen to have the same username? They might get mapped to the same "account" within the app. It might just throw an error.

When you start talking about LDAP and other authentication protocols, you start to blur the line between what is IIS's responsibility and what is the application's responsibility. For LDAP specifically, the web server doesn't care anything about that. Apps that use LDAP authentication typically configure the web server for Basic authentication (hopefully over SSL) and all of the LDAP connectivity is handled within the application logic.

I hate to be a downer. But with a proprietary app and a legacy environment like this, your outlook is not so good.

  • This is going to be a nightmare... 8-| Apart LDAP, I also thought to replicate in some way domainB users in domainA AD server, avoiding username collisions with some trick (prefix), and then (how?) sync their passwords from domainB to domainA, as needed, in some way... I could setup a "service" or esle for this... if you think it could work, do you know where I could look?
    – m.ardito
    Apr 21, 2016 at 12:01
  • You don't want to go down that road. You need to tell your management that this can't be done or that you need to run an additional instance of this application for the other domain. Apr 21, 2016 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.