@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