@rhessinger

Thanks for digging into this, Rich. Here's our actual Samba config:

• Samba version: 4.15.13-Ubuntu
• Topology: single domain, single DC, single site — progetpoc.local (netbios PROGETPOC), DC dc1.progetpoc.local, site Default-First-Site-Name. No second domain, no trusts, no additional sites.
• Domain/forest functional level: Windows 2008 R2 (the oldest Samba supports) — never raised to a modern level.
• ProGet directory config: "Domain controller host" set to a single bare IP (Samba's Docker gateway IP), connection type "Use LDAPS and bypass certificate errors" (self-signed cert, since this is a throwaway test domain).

The thing that stands out to me: this is a single domain / single DC / single site setup — there's no second domain or trust relationship for a query to genuinely need to "refer" to. So on paper there shouldn't be anything to refer to, yet we still consistently get LdapReferralException on the group-membership resolution path specifically (not on basic user/group lookups, which we confirmed work fine). That makes me wonder if this is less about real cross-domain referrals and more about how Samba responds for a specific naming context (Configuration/Schema partition?) during whatever query ProGet's authorization path issues for recursive group membership — rather than a genuine multi-domain referral case like your local test environment might've had.

Happy to grab a full LDAP trace/packet capture of the exact failing query if that would help narrow it down further. Also worth asking: was your local Samba 4 test also a single-domain/single-DC setup, or did it include a trust/second domain? If yours was multi-domain and ours isn't, that might explain why you're not seeing the same exception.

Quick licensing question as we scope production infrastructure: your docs say HA/clustering with InedoDB is an Enterprise-licensed feature (up to 5 servers/instance). Is that included in Enterprise Essentials ($11,995/yr), or does it require stepping up to Enterprise Complete ($29,995+/yr)?

We're trying to nail down a cost comparison between a single-instance (non-HA) deployment and an InedoDB-clustered HA deployment before we finalize our production architecture, and this determines whether that comparison is a ~$3-4K/yr gap or a much bigger one.

Thanks,
Sai

@rhessinger,

Thanks for the quick turnaround, Rich. Tested it — unfortunately it doesn't fix the issue against Samba 4.

What I did:

• Pulled InedoCore-4.0.6-rc.1 from the pre-release extensions feed and confirmed the manifest (version: 4.0.6-RC.1, built 2026-09-23 against ProGet 26.0.11).
• Swapped it in for the stock 4.0.5 extension on our POC instance and restarted ProGet.
• Confirmed the new build actually loaded (not a stale/failed load) — the extension cache picked up new dependencies that weren't present before (Novell.Directory.Ldap.NETStandard.dll, System.DirectoryServices.Protocols.dll).

Result: re-ran the same real package-client request (aduser1 against our nuget-proxy feed) that's failed every time before. Still 401, with the identical signature in the log:

Begin LDAP Get Search Results
LdapReferralException
LdapReferralException
LdapReferralException
End LDAP Get Search Results

No change in behavior at all versus the stock 4.0.5 build. I've reverted our instance back to stock 4.0.5 for now.

Happy to gather anything else that'd help you narrow it down — e.g. a packet capture / verbose LDAP trace from our side, or trying a specific config tweak if you have a theory about what's different in our Samba 4 setup versus whatever you tested referral-following against.

Following up here since it's been a little while with no update.

For the record, we re-tested this again on the official 26.0.11 GA release (not just the rc build) on 2026-09-21, since that release also fixed the separate PG-3374 caching regression — wanted to rule out any chance the two were related. They aren't: aduser1 still fails against a real package-client request (nuget-proxy) with the identical signature as every previous test —

Begin LDAP Get Search Results
LdapReferralException
LdapReferralException
LdapReferralException
End LDAP Get Search Results
401

So this is confirmed as a distinct, still-open issue from PG-3374, unaffected by that fix.

We've settled on a workaround for now — API keys / username-password for package-client auth, treating AD as not viable until this is resolved — so this isn't blocking us day-to-day. But we're moving forward with a production ProGet Enterprise rollout and would like to eventually get AD working for developer convenience, so any update on whether Linux referral-chasing is likely to get enabled (or another fix path) would be appreciated whenever you get a chance to look at it again.

@rhessinger,
Upgraded to 26.0.11-rc.15 and re-ran the exact same tests — confirmed fixed.

ldapuser1 with the correct password authenticates successfully; wrong password correctly rejected. And the real test — ldapuser2 (the second user I added specifically to rule out a stale hardcoded filter) — succeeded on the first try, no restart needed this time. Previously that same scenario needed a docker restart proget to pick up the new permission grant.

Log confirms it's genuinely correct, not just passing by luck:
SRCH filter="(&(objectClass=inetOrgPerson)(uid=ldapuser2))"
BIND dn="uid=ldapuser2,dc=progetpoc,dc=local" method=128
RESULT tag=97 err=0

Correct substitution, correct resolved-DN bind, correct result. This is a real fix — thanks for pointing me at the RC build and for digging into this as much as you did. Data (packages, database) all persisted fine through the upgrade too, for what it's worth, in case that's useful signal for anyone else planning the same jump.

Was told in a separate thread that PG-3374 (the permission/directory-config caching regression) is fixed in ProGet 2026.11, released September 15, 2026. Trying to verify that fix live, but I can't find the build anywhere:

• docker pull proget.inedo.com/productimages/inedo/proget:2026.11 → not found
• docker pull proget.inedo.com/productimages/inedo/proget:latest → still resolves to the same digest as before, X-ProGet-Version: 26.0.10.14
• my.inedo.com/proget/versions → latest listed is still 2026.10 (9/6/2026), no 2026.11 entry at all

This is now six days past the stated release date. Is 2026.11 actually out, and if so, where should I be pulling it from? Or has the release date shifted? Just trying to get an accurate timeline so I know whether to keep checking or move on with 26.0.10.14 for now.

Quick follow-up for the record, not expecting a fix here given what we settled on above — just confirming the behavior is still consistent.

Re-tested a real package-client request against the same setup (aduser1, same feed) and the referral exception reproduces identically:

Begin LDAP Get Search Results
LdapReferralException
LdapReferralException
LdapReferralException
End LDAP Get Search Results
(repeated 3x)
Request finished ... - 401

Same three-stacked pattern as before, still on build 26.0.10.14. No regression, no change — just wanted to leave a clean confirmation on the thread in case this comes up for anyone else searching for it later. Thanks again for the help narrowing this down — treating it as the known Linux/referral-chasing limitation we discussed.

@rhessinger ,

Thanks for the code link, Rich — that confirmed what I suspected: the user-search and group-search paths really are identical (one SearchAsync method, same escaping call, just a different filter string), so I went back and re-tested rather than guess further.

I can no longer reproduce either issue (empty filter substitution or the empty-DN bind). Tested against a rebuilt OpenLDAP container:

• ldapuser1 authenticates successfully via a real HTTP Basic-auth request. Log shows the filter correctly built: filter="(&(objectClass=inetOrgPerson)(uid=ldapuser1))" — not (?uid=).
• The credential-verification bind now correctly uses the resolved DN: BIND dn="uid=ldapuser1,dc=progetpoc,dc=local". A wrong password correctly returns err=49 (invalid credentials) rather than binding anonymously.
• To rule out a leftover hardcoded filter from earlier debugging, I created a second user, ldapuser2, with a different username. Its filter also correctly showed uid=ldapuser2 — genuine %s substitution, not a stale config value.

One side note that might be relevant to your side, not a new report: ldapuser2 got a 401 on its first couple of attempts despite the auth itself being correct in the log — resolved immediately by restarting the ProGet container. Looked identical to the permission-cache issue you already have documented (PG-3374).

I want to be upfront that I don't think you actually shipped a fix here — X-ProGet-Version on this instance is still 26.0.10.14, the same build I originally tested on, not 2026.11. So I can't explain why it's working now. My best guess, given the ldapuser2 cache symptom above, is that this was itself downstream of the same caching regression as PG-3374 — some stale state that eventually cleared with enough restarts, rather than a real code path being broken. I don't have a way to prove that theory either way from my side.

Given that, I'd treat this as "not currently reproducible, cause unconfirmed" rather than "fixed" — happy to keep an eye out and re-test properly once 2026.11 is actually out, if that's useful data for you. Let me know if you want the exact directory config anyway for your own review.

@rhessinger ,

Thanks for the follow-up — tested this directly.

Group search does not have the same issue. Using the directory's "Load group by group name" test tool against the Groups: filter ((&(objectClass=groupOfNames)(cn=%s))), the server's own connection log shows %s substituted correctly:

SRCH base="dc=progetpoc,dc=local" scope=2 deref=0 filter="(&(objectClass=groupOfNames)(cn=proget-users))"
SEARCH RESULT tag=101 err=0 nentries=1

The follow-up "List Group's Members" filter ((&(objectClass=inetOrgPerson)(memberOf=%s))) also substituted correctly — it inserted the full resolved group DN:

SRCH base="dc=progetpoc,dc=local" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(memberOf=cn=proget-users,dc=progetpoc,dc=local))"
SEARCH RESULT tag=101 err=0 nentries=0

(That one came back empty, but that's expected on our end — our test OpenLDAP server doesn't have the memberof overlay loaded, so memberOf is never actually populated on user entries. Not related to the bug.)

So: both group-side filters resolve %s correctly. Only the user-search filter ((&(objectClass=inetOrgPerson)(uid=%s))) produces the broken (?uid=) pattern. Since substitution clearly works elsewhere, I don't think this is a general escaping/value-handling issue — it looks isolated to whatever code path handles the user-search filter specifically. Happy to send the exact directory config (User Search Base, Users filter) again if it helps narrow it down further.

@rhessinger ,

Ran the test you suggested — good news, this narrows it down cleanly.

"Search for groups" (group name Domain Users): succeeded, found 1 group, no referral exception.

"Load user by user name" (aduser1, group Domain Users): also succeeded cleanly — "User aduser1 found," then a clean "Is not member of Domain Users" result (makes sense — Domain Users is aduser1's primary group via primaryGroupID, which typically doesn't show up in memberOf on AD, so that's expected AD behavior, not an error). No referral exception in either test.

So basic group lookup and direct membership checks are both fine — the referral really does seem isolated to whatever recursive/transitive resolution happens specifically in the real permission-authorization path (matching your theory about the magic OID for nested group search), not group operations in general.

Given referral-chasing being disabled by default on the Linux build is the underlying mechanism, that's useful to know regardless of the Samba-4-specific trigger — it's the kind of thing that could surface against a real multi-domain Windows AD forest too, not just our test setup. We'll note that as a known limitation of the Docker/Linux deployment specifically rather than something to expect fixed here. Appreciate you digging into this as much as you have — this has been a genuinely useful back-and-forth for us.

Thanks,
Sai

@rhessinger,

Thanks — good to know about the Advanced tab port field, that resolves our earlier question about host:port syntax.

On the %s question, here's the LDAP object for ldapuser1 (LDIF):

dn: uid=ldapuser1,ou=people,dc=progetpoc,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: ldapuser1
sn: TestUser
givenName: Ldap
cn: Ldap TestUser
displayName: Ldap TestUser
uidNumber: 10001
gidNumber: 10001
userPassword: LdapUser!2026
gecos: Ldap TestUser
loginShell: /bin/bash
homeDirectory: /home/ldapuser1
mail: ldapuser1@progetpoc.local

I think we have evidence that narrows this down, though: we tried the same object with a hardcoded, literal filter — (uid=ldapuser1), no %s involved at all — and that search succeeded cleanly:

filter="(&(objectClass=inetOrgPerson)(uid=ldapuser1))"
SEARCH RESULT tag=101 err=0 nentries=1

So the object itself definitely has a matching uid attribute and objectClass=inetOrgPerson — a real value search finds it fine. The (?uid=) rendering only appeared when the "Users:" field's %s placeholder was in play, with the exact same object as the target. That seems to point at something about how the placeholder gets expanded (or not) before the query is sent, rather than something about our test object's attributes. Does that change your read on it, given the hardcoded-filter result?

@rhessinger
Both fixes worked, thank you — this got us past the two earlier blockers:

• Setting "Domain controller host" to a single bare value (just the IP, 172.17.0.1, no comma-separated list) fixed the earlier "no connection attempt at all" issue.
• Switching "LDAP Connection" to "Use LDAPS and bypass certificate errors" fixed the "Strong Authentication Required" error that appeared once the connection attempt started reaching the domain controller (our Samba AD test server apparently requires signed/sealed LDAP, so plain "Use LDAP" was being rejected at the protocol level).

Using the Test User Directories tool (Login with user name and password, aduser1), authentication now succeeds cleanly:
User aduser1 found:
Name: aduser1@progetpoc.local
EmailAddress: aduser1@progetpoc.local
DisplayName: AD TestUser

But a real package-client request (dotnet restore against the same feed, same credentials, after granting aduser1 "View & Download Packages" on the feed) still fails with 403. Our own server log shows:

Request starting HTTP/1.1 GET .../nuget/nuget-proxy/v3/index.json
Begin LDAP Get Search Results
LdapReferralException
LdapReferralException
LdapReferralException
End LDAP Get Search Results
Request finished ... - 403 ...

So it looks like the actual package-client auth path does a follow-up LDAP search (likely resolving group membership for the permission check) that hits an LdapReferralException three times before giving up, even though the same user authenticates cleanly through the Test User Directories tool moments earlier. Is there a setting to control referral-chasing behavior for this directory type (something like the V4 type's "Search Group Method" — V5's Advanced tab only shows NETBIOS mapping and "Include gMSA")? Or is this a known interaction with Samba-backed AD specifically, since Samba may return referrals for some default partitions (ForestDnsZones/DomainDnsZones) that a real Windows-hosted AD wouldn't surface the same way in this kind of query?

Thanks,
Sai

@rhessinger

Thanks.

@atripp ,

Thanks for the info.

@atripp,

Went back through your docs and our own notes trying to pin down a specific page, and honestly — we can't find one. The closest we got was a page showing how to create a Specified License Rule (e.g., setting GPL-3.0 to noncompliant), but every example there is clearly a user-configured policy, not a factory default. We think our original impression was a general one from early research rather than something we can point to a specific article for, so no need to go hunting on our end — sounds like it was just an assumption on our part rather than something your docs actually claimed.

Good to have it confirmed either way: no default license rule ships out of the box, and creating one (GPL or otherwise) is expected as part of setting up a feed. We'll document it that way.

Thanks,
Sai

@rhessinger

Thanks — tried this. Two updates:

1. Group Search Base did not resolve the %s placeholder issue

Set Group Search Base to the same value as User Search Base (dc=progetpoc,dc=local) and re-tested. The search now completes cleanly (err=0, matching a properly-set base), but the filter sent is still:

filter="(&(objectClass=inetOrgPerson)(?uid=))"
SEARCH RESULT tag=101 err=0 nentries=0

The %s in the "Users:" field ((&(objectClass=inetOrgPerson)(uid=%s))) still isn't being substituted with the submitted username — it collapses to a literal ?uid= with nothing after the =, so it matches zero users regardless of who's authenticating. Screenshots of our current full config (General, LDAP User Filters, LDAP Group Filters) attached.

2. Found something else along the way: Host field doesn't seem to support host:port syntax

While troubleshooting, we temporarily ran our test OpenLDAP server on a non-default port and set Host to 172.17.0.1:1389. With that value, ProGet produced a 403 with zero connection attempts ever reaching the LDAP server (confirmed via its own connection log) and no log entry at any severity in the Diagnostic Center — a completely silent failure, no exception, nothing. Reverting Host back to a bare IP (default port 389) immediately restored the behavior above (a real, logged LDAP query, just still hitting the %s bug). Is host:port meant to be supported on this field, or is there a separate port field we're missing (similar to the Active Directory directory type's "LDAP Port Override")? If it's not supported, a validation error would be a lot easier to debug than total silence.

We are using osixia/openldap OpenLDAP Server with version 1.5.0.

Please find the latest screen shots.

Thanks,
Sai

@rhessinger

Please let me know the release date for PG-3374. OS i can re verify that.

@rhessinger

Please find the below screenshots.

@rhessinger,

Thanks for the detailed answer — that's helpful context, and to confirm: yes, by "bare username" we meant aduser1 (not aduser1@ourtest.local).

We applied everything you suggested on the V5 directory:

• General tab: Domain = progetpoc.local, User name = Administrator, Password = (re-entered, confirmed saved)
• Connection tab: Domain controller host = 172.17.0.1, progetpoc.local (comma-separated, IP first, DNS name second)
• Advanced tab: NETBIOS name mapping = PROGETPOC=progetpoc.local

Used the Test User Directories tool as suggested (User Directory: "AD Test V5", Test Type: "Login with user name and password", User name: aduser1, Password: matching what we set for that account). Result:

Error: Connect Error
[Debug] Search string is "aduser1"...

We also checked our domain controller's own connection log during the test — it shows zero incoming connections, meaning ProGet isn't even reaching the network for this attempt. That suggests the failure is happening locally (e.g. during config/host parsing) rather than a real connectivity or credentials problem.

Our leading suspicion is the "Domain controller host" field's expected format — we entered both values as a single comma-separated string (172.17.0.1, progetpoc.local). Is that the correct syntax, or does that field expect one value per line, a different separator, or only a single value with something else supplying the second lookup? Want to make sure we're not just malforming that field.

Happy to send additional screenshots (any specific tab/dialog) if that helps narrow it down further.

Two issues that reproduced initially, then resolved on their own within a few days — known/fixed bugs?

Two lower-priority items from our Enterprise trial evaluation that we wanted to flag, mainly for our own confidence that they won't regress, since both resolved without any change on our end.

1. pgutil vulns assess returning 500 — for every assessment type, regardless of auth method. Re-tested three days later with no changes on our side — now completes successfully.

2. Non-admin package promotion via the API returning 403 — with every combination of "Promote Packages" permission we could construct, while the identical action succeeded via the web UI. Re-tested the same account three days later with a fresh package — now succeeds via the API too, confirmed by a real download.

Were either of these known issues fixed in a point release during that window, or something else (e.g. a permissions-cache propagation delay, similar to what we found separately with restart-dependent permission changes)? Just want to understand the root cause well enough to trust it won't come back.

Thanks,
Sai