Does Active Directory support require domain-joining, even with "Domain controller host" set?

[sai.pabbareddy]

@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.

[rhessinger]

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

[sai.pabbareddy]

@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]

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

[sai.pabbareddy]

@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

[sai.pabbareddy]

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.

[sai.pabbareddy]

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]

Hi @sai.pabbareddy,

This has not gone through formal testing, but I just pushed a pre-release of the InedoCore extension that includes the referral following on Linux. Would you mine testing it out on your end and see if it fixes your issue with Samba 4?

The fix is included in InedoCore 4.0.6-rc.1. To install a pre-release extensions, see installing pre-release extension in ProGet's documentation.

Thanks,
Rich

[sai.pabbareddy]

@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.

[rhessinger]

Hi @sai.pabbareddy,

I realized that how I was enabling it in code left it disabled still in practice due to how that library handles search constraints. I enabled it the right way and did some testing against a Samba 4 server I setup locally and referral chasing ended up making it so slow that it was unusable. With that said, I'm not getting referral exceptions when testing against it, so there may actually be something else going on. Is there anything unique about how your Samba 4 server is configured?

Thank,
Rich

[sai.pabbareddy]

@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.