Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Integrated Auth Not Working When I Switch to IIS Hosting
-
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?
-
Hi @arozanski_1087,
It may be easier to disable Integrate Windows Authentication and then try to migrate it to IIS. If you do that, does everything work? Or do you see errors? If you see errors, what are they?
Thanks,
Rich
-
@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.
-
Hi @arozanski_1087,
I apologize, can you please clarify this for me? Are you referring to ProGet connecting to SQL Server altogether or a user logging in with integrated authentication?
If it is ProGet connecting to SQL Server, please check the user on the Application Pool in IIS has access to the database. You may either need to change what user the application pool is running as or you will need to add the application pool user to the SQL Server database (ex:
IIS APPPOOL\ProGet) You can only add an App Pool user if SQL Server in on the same server).Thanks,
Rich
-
@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.
-
Hi @arozanski_1087,
Thanks for clarifying that for me. You will also need to make the ProGet windows service run as that account also.
Your SQL Server Connection string should look similar to this:
Persist Security Info=False;Integrated Security=true; Initial Catalog=ProGet;Server=<SQL SErver Name>When you add your service account to SQL server, are you using the UI or are you using a SQL script? I ran into some weird issues using a service account where the only way SQL Server would format it correctly was by adding it through the UI. This was probably due to the unique environment at that company, but I have seen that happen.
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.)
Thanks,
Rich
-
@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.
-
Hi @arozanski_1087,
Technically they do not need to run as the same account, but it does simplify things. Especially since they share the configuration file that contains the connection string. Also, please make sure that your IIS has the correct features installed. You can see the Configuring IIS Roles & Features for Inedo Products documentation for that information. Were you using that exact service account previously on the integrated web server install? If you were there shouldn't be any iossue connecting from IIS then.
Thanks,
Rich
