Handling contracted domain names in 'Active Directory with Multiple Domains'

Hi,
I really appreciate the updated UI and the updates regarding user directories!

Background

We have two domains accessible through different forests:

ourdomain.local

x.ourdomain.y

I successfully added privileges to groups in the local domain:
developers@ourdomain.local

After switching user directory to 'Active Directory with Multiple Domains'
I can log in using any user in the group when I provide the FQDN using forms-authentication.

So far so good!

Problem

The problem is with windows authentication. When I enable integrated authentication IIS identifies me as:
user@ourdom (should be user@ourdomain.local)

The problem is probably in our setup but since my identity contains the domain name in short form it doesn't match any of the principal names... Is this solvable?

Kind regards,

Hasse

Product: ProGet
Version: 3.8.1

Hi Hasse, thanks for the detailed write-up.

Actually, thanks to another ProGet customer, we do have a fix in mind. Here is what he wrote:

The problem is based on two facts.

First. Integrated authentication means that you receive the user identity in the form of "netbios_domain_name\user_name", i.e. in our case domain2\user2. Nothing's wrong with that.

Second. You assume that the netbios name is the same as the FQDN, and use this domain in your directory search. That's absolutely wrong. These names are not supposed to be identical (not even similar). This is the root of the problem, and we need to fix it.

If we send you some C# code to query / test your own domains, will you be able to run it and see if it would work in your environment? We can then integrate the code into the Multi Domain LDAP provider.

That was the fastest response I've ever gotten on an issue board :)

I would be glad to test it in our environment!

luke.duddridge_1525

Hitting the same problem with v4.0.15.

@Hasse did you ever resolve this or just move onto a new feed provision?

Currently left at 3.6.1, which works out the domains correctly.

Unfortunately, the problem you're experiencing is a different problem altogether, and is more of a UI issue (the user/group principal browser is not constructing the principal names using the needed format for your domain).

It seems to only impacts a very small number of multi-domain instances, but it's on our list. The easiest workaround is to directly add the names to the [privileges] table.

Hi Alana,

Any chance of sending that C# code to me as well? We are also facing issues getting multi-domain AD working.

TIA