I'm a bit confused by this, because this is exactly the type of scenario where Network Service does make sense (I thought).

It's not true to say that Network Service 'isn't a domain user' - it is, but presents as the identity of the hosting machine (ie domain\machine$ not domain\network service). But I'd be amazed if that needed special permissions to talk to AD (after all - surely the same underlying credentials and operations are underlying Win32 LookupAccountName), and Stack Overflow concurs (in 2011 at least): .net - Query Active Directory under NT AUTHORITY/NETWORK SERVICE - Stack Overflow

I think there's something else going on here.

On Fri, 24 May 2024 at 07:09, Greg Keogh via ozdotnet <ozdotnet@ozdotnet.com> wrote:
TGIF!

I just spiced-up an ASP.NET app so that it uses DirectorySearch.FindOne to either verify a login user account exists or to authenticate. It runs perfectly on my work PC, but when I installed the app in IIS on my test server it died with The specified domain either does not exist or could not be contacted. I discovered that because my app was running as NETWORK SERVICE, which isn't a domain user, it can't see the Active Directory.

A trap...only domain user accounts can see AD. Asking the customer (a hospital) to create a special account, assign it to the pool and set ACLs is impractical. My lovely new login feature has hit a roadblock and I'm not sure of a workaround or alternative. It's a specialist topic, but I thought I'd ask in here just in case some boffin has suggestions.

Greg Keogh

P.S. I just remembered that about 15 years ago I used a Win32 Interop to call LoginUser for a similar purpose, but it was for local accounts and I'll need to research if it works for domain accounts.
--
ozdotnet mailing list
To manage your subscription, access archives: https://codify.mailman3.com/


--
piers