.NET 4.5 Bug in UserPrincipal.FindByIdentity (System.DirectoryServices.AccountManagement)

Question

In testing our .NET 4.0 application under .NET 4.5, we\'ve encountered a problem with the FindByIdentity method for UserPrincipal. The following c

Answer 1

To the OP (and anyone else that helped with replies) we have(had) the same exact issue. In our development environment, installed VS2012 and our app broke at runtime during login (AD issue as pointed out above). So I had my system wiped and continued using 2010, all the while shedding a tear every time Id read a new blog post about how awesome 2012 is blah blah.

So I found this thread thanks to Scott Hanselman. I installed a VM on my development box, Windows 8 developer 90day preview on it, and VS2012. Got our Application up and running and immediately was hit with the login AD snag. Simply wrapped our FindByIdentity in a try catch and forced it to try again after the first catch - and viola it works!! So thanks to whoever figured that little trick out!!

So, its a minor fix, and a "hack" that works for local development, and shouldn't affect production since we aren't putting 4.5 on production any time soon.

But the downside is that locally, logging in now takes like 2 minutes versus seconds when we ran under 2010 :(

I don't really know what else I can provide to actually try to help solve the situation, but figured Id share my 2 cents anyway since this still appears to be a major issue.

Answer 2

We are experiencing the exact same issue (cross domain queries failing on updating to 4.5) - I would consider this a bug since it breaks existing (4.0) code.

However, in the interest of making it work - taking a look at one of the (now) failing clients, I noticed that there were a bunch of DNS requests for SRV records that were failing, of the form:

_ldap._tcp.MYSERVER1.mydomain.com,INet,Srv
_ldap._tcp.dc._msdcs.mydomain.com,INet,Srv

Modifying our DNS server (the DNS used by the failing clients) to have a forward zone for all mydomain.com traffic to one of the DCs on the domain did resolve the issue.

Using nslookup, the behavior from before (when it was failing) to now (working) was that before those queries would return "Non-existent domain" whereas now they return "* No Service location (SRV) records available for ...". The point of failure seems to be the perceived nonexistence of the domain rather than missing SRV records. Hopefully MS reverts this behavior but in the meantime you might have some luck creating a DNS forward zone if you can control the DNS for the failing clients.

Answer 3

Had same problem after upgrading .net framework from 4.0 to 4.5 I have ugpraded framework to .net 4.5.1 and it worked.