@Stephen-Schaff ah that's too bad, quite frustrating! Any luck setting up test server, so it doesn't' inconvenience production?
I don't why it didn't work, but it's not what I would have expected.
We had been assuming this was failing in the TryParseLoginUserName method, which is where that NETBIOS mapping occurs. It seems to be working fine, and is surprising to see.
Instead, it seems to be failing in TryGetUserAsync, which calls the TryGetPrincipal method. The TryGetUser method is called in a bunch of places (and when it returns null for an authenticated user, you'll get that can't find user error), but it's also on the "Configure User Directory Page", when you hit the "test get user" button.
You showed that you tested the connectivity using "test search", but there's good reason one query (get) would work, but not the other (search).
That doesn't make a lot of sense to me. I'm thinking, another test from that page is in order.
Here's the (messy) code for /debug/integrated-auth.
WriteLine($"Id:\t\t{domain.Id}");
{
var messages = new List<string>();
WriteLine("---------");
var ad = WebUserContext.CurrentUserDirectory;
ad.MessageLogged +=
(s, e) => messages.Add(e.Message);
var parsedLogonUser = ad.TryParseLogonUser(context.Request.ServerVariables["LOGON_USER"]);
if (parsedLogonUser == null)
WriteLine("Could not parse LOGON_USER.");
else
WriteLine("LOGON_USER parsed as: " + parsedLogonUser.Name);
var user = await ad.TryGetUserAsync(context.Request.ServerVariables["LOGON_USER"]);
if (user == null)
WriteLine("Username not found.");
else
WriteLine($"Username:\t\t{user.Name}");
WriteLine("Additional messages:");
foreach (var m in messages)
WriteLine(" - " + m);
}
Here's the (messy) code for the "Test" button next to "Test get user" on that page:
var btnTestGetUser = new PostBackButtonLink("Test", () =>
{
var log = new StringBuilder();
try
{
instance = instance ?? (UserDirectory)Activator.CreateInstance(this.Type);
editor.WriteToInstance(instance);
instance.MessageLogged += (s, e) => log.AppendLine($"[{e.Level}] {e.Message}");
var principal = instance.TryGetUser(txtTestUser.Value);
if (principal == null)
{
divSearchResults.Controls.Add(InfoBox.Warning(new P("User ", new Element("code", txtTestUser.Value), " not found.")));
return;
}
else
{
divSearchResults.Controls.Add(InfoBox.Success(
new P("User ", new Element("code", txtTestUser.Value), " found: "),
new Ul(
new Li("Name: ", principal.Name ?? ""),
new Li("EmailAddress: ", principal.EmailAddress ?? ""),
new Li("DisplayName: ", principal.DisplayName ?? "")
)
));
if (!string.IsNullOrEmpty(txtTestUserGroup.Value))
{
if (principal.IsMemberOfGroup(txtTestUserGroup.Value))
divSearchResults.Controls.Add(InfoBox.Success(new P("Member of ", new Element("code", txtTestUserGroup.Value))));
else
divSearchResults.Controls.Add(InfoBox.Warning(new P("Is not member of ", new Element("code", txtTestUserGroup.Value))));
}
}
}
catch (Exception ex)
{
divSearchResults.Controls.Add(InfoBox.Error(new P($"Error: {ex.Message}")));
}
if (log.Length > 0)
divSearchResults.Controls.Add(new Element("textarea", log.ToString()) { Style = "width:500px; height:50px;" });
divSearchResults.Visible = true;
});
Lots of code, but I wanted to share both of these, so we're looking at exactly the same thing, if you need it.
** Can you try testing "get user" again (not "search user") using that page? You will most certainly see the exact same set of error messages. **
If this is the case, then the problem is most definitely related to credentials/permissions, and really doesn't seem to be related to NETBIOS alias, after all.
Next steps.
- Confirm that you're getting same error from the "Get user" test but that "Search user" works
- Remove the NETBIOS alias mapping, make sure results are identical (get doesn't work, search does)
- Enter wrong credentials, like a bad username or bad password; ensure that "Search user" fails
- Correct the credentials, and makes sure that "search user" works again
- Try your own, personal credentials to see if it makes a difference
- Disable LDAPS (if it was enabled) and try again
- Create a ProGet test server, see if you can replicate behavior
- Open a ticket with Microsoft with replication results (the tool works, the servers don't, etc)
I hate that last step... but there's no reason on earth why this same, basic query that's run by the same C# code using the same credentials would work in one environment (desktop app on one server) but not another (web app)
)... but behind-the-scenes it's .NET, and that means we can use nullable value types.
