Topics created by mhelp_5176

I was trying to do the same thing. These are the steps I took to get it working. Some of the steps I gave examples for both a standard service account and a group managed service account to help show how to do it either way. The PostgreSQL references to the group managed service account can be swapped for the service account if a standard service account is the preference. File Permissions Change only the 'ProGetService' logon_as to service account. Note: If using a Group Managed Service Account, leave the password fields blank Grant 'Full Control' permissions over each directory configured in Advanced settings for the following settings: Extensions.BuiltInExtensionsPath Extensions.CommonCachePath Extensions.ExtensionsPath Storage.PackagesRootPath Storage.LocalStoragePath Certificate Key Permissions Navigate to the certificate used by the server for SSL encryption: Start > Run > MMC File > Add/Remove Snap-in... Add 'Certificates' for "Computer Account" In the Personal certificates store, right-click the appropriate certificate, select "All Tasks > Manage Private Keys..." Add the service account and grant it 'Read' permissions HTTPS Binding to a Hostname Edit C:\ProgramData\Inedo\SharedConfig\ProGet.config Update 'WebServer' Urls element to use "https://*:443". Note: Using the hostname instead of the wildcard will cause all feeds and assets to use Windows Integrated Authentication making any attempt to authenticate with an API key fail. Run the following from an elevated administrator privilege console: (Service Account) netsh http add urlacl url=https://*:443/ user=svcServiceAccount <or> (Group Managed Service Account) netsh http add urlacl url=https://*:443/ user=DOMAIN\gmsaServiceAccount$ Execute the command: netsh http add sslcert hostnameport=myproget.com:443 certhash=<thumbprint> certstorename=My appid="{E7FD8489-4931-45D9-8D42-427367B12584}" Run as a user with domain administrator privileges: (Service Account) setspn -U -S HTTP/server.fqdn.com svcServiceAccount <or> (Group Managed Service Account) setspn -S HTTP/server.fqdn.com gmsaServiceAccount PostgreSQL SSPI Authentication Edit C:\ProgramData\Inedo\SharedConfig\ProGet.config Note: Save the password from the database connection string as it will be needed to connect to the database later Update the connection string to delete the 'Password' attribute and value, change the username to 'Username=gmsaServiceAccount$@DOMAIN" Note: The user name must end with the '$' character if it is a group managed service account. Also the name is case sensitive. Edit C:\ProgramData\ProGet\Database\pg_hba.conf Add the following line: host all gmsaServiceAccount$@DOMAIN 127.0.0.1/32 sspi PostgreSQL Login/Group Roles Execute the command: "C:\Program Files\ProGet\Service\postgres\bin\psql.exe" -d proget -U proget -h 127.0.0.1 -p 5728 -c "CREATE ROLE ""gmsaServiceAccount$@DOMAIN"" WITH LOGIN SUPERUSER INHERIT CREATEDB CREATEROLE REPLICATION BYPASSRLS;" When prompted, enter the password that was saved from the database connection string in C:\ProgramData\Inedo\SharedConfig\ProGet.config <or> You can create a SQL script file named C:\Temp\init_roles.sql and add the following: -- Role: "gmsaServiceAccount$@DOMAIN" -- DROP ROLE IF EXISTS "gmsaServiceAccount$@DOMAIN"; CREATE ROLE "gmsaServiceAccount$@DOMAIN" WITH LOGIN SUPERUSER INHERIT CREATEDB CREATEROLE REPLICATION BYPASSRLS; Execute the script: "C:\Program Files\ProGet\Service\postgres\bin\psql.exe" -d proget -U proget -h 127.0.0.1 -p 5728 -f C:\Temp\init_roles.sql Alternatively, you can install pgAdmin (https://www.pgadmin.org/download/pgadmin-4-windows/) and add the role by navigating down the Object Explorer, right-clicking on 'Log/Group Roles > Create > Login/Group Role...' Give the name in the format "gmsaServiceAccount$@DOMAIN", and on the Privileges tab enable all privileges, then Save.

Hi @mhelp_5176 , I haven't investigated BitBucket Cloud any further, but it sounds like there's an issue with the integration -- and it's definitely something we can look at later. My guess is that it's some kind of change to the API/authentication. But we're all pretty focused on getting ProGet 2025 out the door, so it'll have to be after that. That said, the main difference between connecting to a "Git host" like GitHub, GitLab, Gitea, BitBucket, etc. vs a "generic Git repository" is that there will be some intelligent drop downs to help you select a repository. There are a few other differences as well, but mostly it's UI. So for example, on a GitHub connection, you'll see a list of organizations and repositories, and then would select the one to connect to. Compare this to the "Generic Git repository", where you simply paste in the repository clone url. But in either case, you need to configure each repository connection individually; typically each application will have one repository, which is why this is part of the application creation process. It's definitely not a common practice to be able to "pull in all the repositories in a workspace" at once - that's not really how Git works, and it would involve some kind of script that iterates a list of repositories and clones/updates each one indivdiaully based on configured remotes in subfolder., Cheers, Alana