AD authentication fails after IIS deployment

Hi All,

Very excited to see radzen 'at work' and successfully build an app on the local dev PC. Using AD authentication wo issues, I have followed the deployment documentation to the tee, however after deploying it on IIS the authentication fails with the error described below (grabbed with Chrome Dev Tools). Any idea what I might have possible missed here, either on the IIS/SQL Server side, OR on the app side?

Thanks in advance,

An unhandled exception occurred while processing the request.

SqlException: Login failed for user 'DOMAIN\MACHINENAME$'.
Microsoft.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, bool breakConnection, Action wrapCloseInAction)

Hi @AlexGI,

Most probably the domain user doesn't have access to the SQL server instance. You need to either use SQL server authentication (with user name and password) or allow access to that SQL user.

Hi korchev,

Thanks for the quick reply. That was my first obvious 'light bulb' as well, but the user is both a domain admin AND a sysadmin at the SQL Server instance level, yet it doesn't make a difference... It seems to me that it boils down to how IIS taps into SQL Server, both of which are hosted by the same server btw (aka ).

For what matters, here is the data source connection string used for the environmentVariable declared at system.webServer/aspNetCore level:

Server=;Initial Catalog=;Persist Security Info=False;Integrated Security=true;MultipleActiveResultSets=False;Encrypt=false;TrustServerCertificate=true;Connection Timeout=30



In my reply above I've noticed the 'disappearance' of the entities encroached by the "less-than" sign, so here is the connection string as I've intended to have it displayed:

Server=MACHINENAME;Initial Catalog=DATABASENAME;Persist Security Info=False;Integrated Security=true;MultipleActiveResultSets=False;Encrypt=false;TrustServerCertificate=true;Connection Timeout=30

(obviously I have replaced the real server/database names)

IIS usually runs with its own user unless configured otherwise. This seems like a local configuration error which isn't related to Radzen.

Thanks for confirming, and yes, I found that the Identity of the DefaultAppPool was the difference-maker ('ApplicationPoolIdentity' vs 'NetworkService').