Hi @sai.pabbareddy,

Glad to hear it all works as expected!

Thanks,
Rich

Hi @sai.pabbareddy,

Thanks for the heads up. The cache fix should exist in 26.0.11-rc.15, but I'll be very interested to hear if you still see those issues after the upgrade. Please keeps us informed and we can look into it further.

Thanks,
Rich

Hi @sai.pabbareddy,

My apologies. Looks like I typoed the date on that other post. I had the day of Friday correct, but the date should have been Sept 18, 2026. It will be releasing later today (normally in the evening in EST). I updated that response also to have the correct date.

Thanks,
Rich

Hi @sai.pabbareddy,

I think it would be a good idea to have you send over the exact directory config. The code paths for searching for users and groups are virtually identical, with the only difference being the LDAP filter. You can see what we are doing directly by looking at the code in GitHub: https://github.com/Inedo/inedox-inedocore/blob/16155c425cf4b4d180e2e7ced7af90e36fb4ed35/InedoCore/InedoExtension/UserDirectories/OpenLdap/OpenLdapUserDirectory.cs#L300

I'm guessing there is something else going on that is causing this, maybe a hidden unicode character or something. When you paste in the ldap queries, can you make sure to include them using a markdown code block (``` ... ```)?

Thanks,
Rich

Hi @sai.pabbareddy,

Let me run some other tests. It could be related to the LDAP escaping that is happening, but that would be highly unlikely as we have many other users currently using the OpenLDAP/Generic LDAP user directory. I think the more peculiar thing is that when you hard coded the uid, the logs didn't show ?uid=, but with the %s it did. That makes me think that it does not like the value that is being passed in. Does the group search have the same issue and log message?

Thanks,
Rich

Hi @sai.pabbareddy,

Glad to hear those settings fixed the initial error.

The LdapReferralException is probably an issue with Samba 4's communication pattern. An LDAP referral typically happens when the AD server is handing off the AD connection to a different LDAP server. The fix is traditionally to connect ProGet to the upstream LDAP server directly. As ProGet supports multiple user directories to be active, this typically isn't a problem. My guess is that Samba 4 uses referrals as a hack for some issue that came up with AD. Based on your comments, I'm guessing the hack is to fix something how it looks up groups (or recursive groups), but I can't confirm that for sure. In v5, we moved this user directory to Active Directory only and force the magic OID for recursive group searches that Microsoft uses.

You can test if the group portion is the issue by selecting the load by username option in the Test User Directory option and entering a group and username.

We have not seen any direct Samba 4 ProGet users in support as of yet, so Samba 4 quirks are still a bit unknown to us. Looking at the code, it is most likely due to ProGet running in a container versus installed on Windows. We have to use a different library for LDAP based on the operating system. In this case, I think the issue is that referral chasing is disabled by default on linux. We can enable that feature in code, but it will require some extra testing on our part because this affects ALL ldap queries on the docker version of ProGet.

Another option is to use the OpenLDAP/Generic LDAP user directory and configure it for Active Directory.

Thanks,
Rich

Hi @sai.pabbareddy,

The port can be changed to a custom port on the advanced tab.

It looks like the %s is actually working in ProGet, but instead this is a feature of osixia/openldap OpenLDAP Server. When the logs shows a ? mark in front of an attribute in a sqerch query (like ?uid=), it means that either the uid attribute is missing of the objectClass does not exist, which therefore cannot confirm that uid exists on those objects. It also could be that the value is hidden for security reasons and you have to change your logging level to see. If you can provide me with the LDAP object for ldapuser1, I can help you build the proper search queries.

Thanks,
Rich

Hi @sai.pabbareddy,

You will have to also set the Group Search Base as well. Can you test that and let me know if anything changes?

Also, what OpenLDAP server are you using to run these test with?

Thanks,
Rich

Hi @sai.pabbareddy,

We will be releasing ProGet 2026.11 this Friday, September 18th.

Thanks,
Rich

Hi @sai.pabbareddy,

The Domain controller host field does not accept a comma separated list. I meant first try setting that to the IP address of your domain controller and then test the connection. Then if that works, then change the value to the DNS name of the Domain Controller (just progetpoc.local) and test it again. That just helps to verify if there is a DNS lookup issue.

Thanks,
Rich

Hi @sai.pabbareddy,

Thanks for the details here. For 1, looking at the code, this is to be expected. We wrote this with the expectation the host would be a DNS name and we used that to build the search base for users and groups. The trade off is that if an IP address is used, then you will need to manually specify the search bases. WE will update our documentation to reflect this.

As for 2 and 3, I'm unable to recreate what you are seeing. Could you please provide screen shots with the values you have configured for the OpenLDAP User Directory?

Thanks,
Rich

Hi @sai.pabbareddy,

For case 1, there is a cash of the users permissions for a short while (~5 minutes). You can force a cache reset on Administration -> Manage security -> Tasks/Permissions page, hover over Test Privileges, and then click Clear Cache. That will force the operation to take effect immediately. This is most likely happening because the bad user was already logged in prior to the change of permissions.

For case 2, that same cache from case 1 looks like it also affects this as well and the clear cache button should also fix this. Looking at the code, it looks like there was a regression that removed the user directory cache clearing, but left in the user privleges cache clearing.

I added a ticket, PG-3374, to fix these and it will be released in ProGet 2026.11.

Thanks,
Rich

Hi @sai.pabbareddy,

When you explicitly set the Domain on the General tab (both v4 and v5), it does not require the need for the server to be joined to the domain. The Domain controller host field just specifies the address or DNS name for your domain controller(s). It will, however, still scan for NETBIOS names. I would recommend setting the Domain to your domain "ourtest.local", the Domain controller host first to the IP address of your samba 4 domain and second the dns name ("ourtest.local"), and add a NETBIOS mapping (ex: OURHOST=ourhost.local) on the Advanced tab. That removes all discovery from AD v4 and v5 and should help to verify any connection problems.

When you say bare username, do you mean "aduser1" and not "aduser1@ourhost.local"?

If you are still having issues, test using the Test User Directories button in the upper right corner and send us a screen shot of the output. That can give us a better direction to point you for further troubleshooting.

Thanks,
Rich

Hi @hardik.turakhia,

When you say external (org) PostgreSQL database, are you referring to a PostgreSQL database you are already hosting in your network and the one that is in the docker compose was for testing? Or are you just trying to host PostgreSQL in a separate container than ProGet, but both controlled by that single Docker compose file? If you are not using HA/Load Balancing, we recommend using the Embedded database. In a HA/Load Balancing environment, we recommend using InedoDB.

If you are still planning to use an external PostgreSQL database (InedoDB or PostgreSQL directly), here are some things to get you started. First, only InedoDB or ProstgreSQL 17 is supported. With that said, your ProGet service in your compose file is not quite right. You have duplicate volumes and your environment variables are using unsupported keys. A good starting point for you should be to review our Docker Compose guide and our Docker guide. Based on that, here is a better ProGet service node that can get you started.

  pg:
    image: proget.inedo.com/productimages/inedo/proget:26.0.9
    container_name: proget
    restart: unless-stopped
    ports:
      - "8624:80"
    volumes:
      - ./proget-packages:/var/proget/packages
    networks:
      - proget
    environment:
      - PROGET_POSTGRES_CONNECTION_STRING: Server=postgres;Port=5432;Database=proget;Password=Pass@123;Username=root;
      - PROGET_ENCRYPTION_KEY: ${ENC_KEY}

I removed the volumes for database and backups since you are planning to use an external database. I'm also using ./proget-packages/ for the volume mount. You had duplicates specified in your volume mounts, so update that path if you want to store it elsewhere. Then you need to specify the connection string for your PostgreSQL database in the PROGET_POSTGRES_CONNECTION_STRING environment variable. Lastly, I added the encryption key environment variable. You can generate this initially using head -c16 /dev/urandom | xxd -p -c32, then you will want to make sure you do not change it going forward. That should be enough to get you up and running.

For other volumes you might want to use see our other volumes section in our Docker guide. For other supported environment variables, see our supported environment variables section in our Docker guide.

Thanks,
Rich

Hi @joris.guex,

Thanks for the feedback. I think you can see why the original error came to be! I tested with cargo 1.92.0 and the extra seconds did not cause issues in my client. I just updated to 1.97.1 and I was able to recreate the issue. I just created a ticket, PG-3345, to track the fix. There is also a new ProGet 26.0.9-ci.1 image that contains the fix.

Thanks,
Rich

Hi @joris.guex,

Thanks for bringing this to our attention. I have created a ticket, PG-3344, to track the fix and I'll be able to get in in with today's release. Here is a prerelease build of ProGet 2026.8 that includes the fix:

https://proget.inedo.com/containers/tags/ProductImages/inedo/proget/26.0.8-ci.4/overview

Thanks,
Rich

Hi @caterina,

Can you navigate to https://«PROGET_HOST»/debug/integrated-auth and send the contents of that page over to us? If need be, you can submit that as a security ticket to us if there is private information in there you do not want to share on the forums.

Can you also try searching for the user using the format of «NETBIOS_DOMAIN_NAME»\«USER_NAME» and verify that mapping is still working?

Thanks,
Rich

Hi @jeremy-oaks_9309,

Glad to help! Please let us know if you have any issues with the migration.

Thanks,
Rich

Hi @jeremy-oaks_9309,

After digging into this further, there are a handful of issues that have all hit here. Before I dive into these, is there a reason you chose to use InedoDB over using the embedded database? Our guidance is when using a single ProGet container, use the embedded database. InedoDB is only recommended to be used with clustered installations of ProGet.

In your case for using InedoDB and ProGet, there were basically 3 main issues that occurred.

Issue 1:
Your docker compose file is not quite correct. You currently have your volume mappings backwards which will cause your data to not be persisted through restarts. This is also why when you updated the the pg_hba.conf file, it did not persist. I should also point out there was a typo in our DockerFile, which pointed to the wrong directory for an InedoDB volume path. This is fixed in InedoDB 17.10.2. We also updated our InedoDB Docker Installation Docs to include the volume as well.

Here is a modified version of your docker compose that will fix these issues:

services:
  inedodb:
    image: proget.inedo.com/productimages/inedo/inedodb:17.10.2
    container_name: inedodb
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
      - /mnt/volume_nyc1_proget/postgres:/var/lib/inedodb

  proget:
    image: proget.inedo.com/productimages/inedo/proget:26.0.5
    container_name: proget
    restart: unless-stopped
    depends_on:
      - inedodb
    ports:
      - "8634:80"
    environment:
      PROGET_POSTGRES_CONNECTION_STRING: Host=inedodb;Port=5432;Database=proget;Username=inedodb;Password=<REDACTED>
    volumes:
      - /mnt/volume_nyc1_proget/proget/packages:/var/proget/packages
    deploy:
      resources:
        limits:
          memory: 2g

Issue 2:
The default for pg_hab.conf was too restrictive. This was actually updated in the Windows installer, but not in the inedodb create --name=proget command. This has now been fixed in InedoDB 17.10.2 and it will work out of the box. With that said, it is stored in a persisted volume, so changes will stay in affect. The other part of this is that when create a database, the container needs to be restarted. We have now added a message in the inedodb create command to restart the container.

Issue 3:
The connection string confusion. This is a side effect of Docker. When we generate the connection string in InedoDB, we use the get host name command from within the container. That hostname does not match the container name or network alias of the InedoDB . We have now added a warning when creating a database in InedoDB on Docker that you may need to update the host in the connection string.

With all those addressed in docs and InedoDB 17.10.2, you should be good to create a new ProGet instance with InedoDB. If you have already started adding packages using your existing setup, I would be worried that your database and package files are not persisting through restarts. I would recommend:

1. Set up a new instance using the DockerFile I used above and a trial key
2. Import your packages from that instance to the new instance
3. Shut down you old instance and move the license key to the new instance

I know this is kind of long, so if you are confused on anything or have any other questions, please let me know!

Thanks,
Rich

Hi @jeremy-oaks_9309,

Thanks for bringing this to our attention. This looks like a change will will need to make to the InedoDB container. Let me do some digging and I'll have an update for you soon.

Thanks,
Rich