I recently rebuilt my ProgGet server (licensed ProGet basic), setting it up on IIS and serving the website over https://:443. As a part of the rebuild, I enabled Integrated Auth so we could use our windows accounts.

Everything was working fine up until maybe a couple of hours ago when the server crashed while looking up an ADO so that I could assign permissions. As I re-opened the tab I found myself unable to login as "The Server Is Not Operational" errors appeared on the login.

I tried what was listed here: https://forums.inedo.com/topic/1349/active-directory-authentication/2 with a service account but wasn't able to rectify it.

What else can I do to diagnose this?

@rhessinger said in Integrated Auth Not Working When I Switch to IIS Hosting:

As long as the Application Pool and Windows Service run as that account and you add that service account to have the ProGet database access as you listed above, there should not be any issues authenticating. I have also seen some companies that have GPO require users to run as a service to be setup within Group Policy. Can you verify you do not have any run as a service restrictions? You can also try to add that user to run as a service locally on that computer (you don't typically need that, but service accounts operate slightly different.)

I used a SQL Script to create the account. The app is currently running under a service account, and has been for over a year. I added that service account to our GPO a while ago so that it would have zero issues with permissions executions and the like. I did not realize you had to have both service and UI under the same account as you said above though (and it is probably why I'm having issues switching). My current setup needs the service account because of how we're storing nuget packages in Azure BLOB (it's been converted into a windows fileshare path, and this was the only way we could make it work when this was setup because it was freeware version and not paid basic at the time), and the way it's connected. Seeing your reply makes me want to entirely redo the setup on another machine to see if I could get this to operate smoother.

@rhessinger I am specifically referring to connecting to SQL.

The Integrated Auth issues I have are from the proget server itself connecting to SQL (also on the same machine). I had the IIS App Pool setup to be default settings and use AppPoolIdentity. It's because of this that I created login for it under Domain\ProgetServerName$ in SQL, and tried granting it dbo and proget_user roles on the Proget DB it created under LocalHost\Indedo when it installed MSSQL. Because Integrated Authentication against it wasn't working, I had tried and failed to reconfigure it to use a service account on the app's configuration files and in the app pool itself by specifying the service account (it still only wanted to use Integrated Auth for some reason like I mentioned in my last reply).

I hope this clarifies it.

@rhessinger I wasn't able to disable integrated Auth. That was one of the peculiar things about my problem. I created a connection string and added it via the Inedo Hub launcher, and also through the shared configuration file*. After restarting the service and IIS after each change, ProGet still only acted as though I had failed login via Integrated Auth, even though I clearly had a password specified and the flag for Interated Auth was no longer in the db connection string.

Setup:

• ProGet 5.3.9 Basic
• Running on Windows Server 2016
• Standard Installation, no unique configurations.
• SQL Server is what's installed with the Service, and Authentication is Integrated, so it uses the machine to login.

Last Night I tried to switch ProGet from using the Integrated Web Server, and host it on IIS. I followed the documentation on the website and installed all components, however It failed to login to SQL for the server. I opened SSMS and granted it every role and permission I possibly could, including the ProGet User Role that was in the database. However it still fails to login for the server via integrated Auth. I tried a few times to switch this to a service account with the documentation listed for editing the shared config, but despite my iis and service resets it never treated the shared config as updated.

This only happened when I uninstalled the WebService and tried to use IIS. After about 4 hours of this I deleted IIS and reinstalled the webserver service, and it all was fine.

How should I proceed?