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

sai.pabbareddy

Related to a separate question we posted about the OpenLDAP/Generic LDAP directory type — this one is about ProGet's purpose-built Active Directory support instead, since we assumed it might be a separate code path.

Our ProGet instance runs in Docker on a Linux host that is not domain-joined (a real constraint for us — we can't easily join this host to a Windows domain). We stood up a real Samba Active Directory domain controller for testing, confirmed a genuine domain user via samba-tool (sAMAccountName=aduser1, userPrincipalName=aduser1@ourtest.local), and tried to authenticate against it using both Active Directory directory types, across six configurations:

V4: Active Directory/LDAP, with an explicit "Domain controller host" override (since we're not domain-joined) — bare username.
Same V4 directory, after confirming it was explicitly enabled.
V5: Active Directory (the newer type, with its own "Connection" tab exposing the same host-override field) — bare username.
Same V5 directory — UPN-format username (aduser1@ourtest.local), in case ProGet only routes domain-qualified logins to this directory type.
Discovered the bind account's Password field had silently not persisted on save — re-entered it and retested.
Reconfigured our ProGet container's DNS to resolve our test domain (in case domain discovery happens before the host override is used) and retested.

All six produced an immediate 403, and in every case, our domain controller's own connection log showed zero incoming LDAP connections — meaning ProGet never even attempted to reach it. We ruled out the obvious environmental explanations: raw TCP connectivity works, DNS resolution works from sibling containers, the directory was confirmed enabled, and ProGet's own server logs show 200 OK on both the credential save and the enable action.

Is the "Domain controller host" override on V4/V5 meant to fully bypass the need for the ProGet host to be domain-joined, or does Active Directory support still require an actual domain join under the hood regardless of that field? If domain-joining is required, is that documented anywhere specific to Linux/Docker deployments — we want to make sure we're not missing a supported way to do this without a domain-joined Windows host.

Thanks,
Sai

rhessinger

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

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