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:

1. V4: Active Directory/LDAP, with an explicit "Domain controller host" override (since we're not domain-joined) — bare username.
2. Same V4 directory, after confirming it was explicitly enabled.
3. V5: Active Directory (the newer type, with its own "Connection" tab exposing the same host-override field) — bare username.
4. Same V5 directory — UPN-format username (aduser1@ourtest.local), in case ProGet only routes domain-qualified logins to this directory type.
5. Discovered the bind account's Password field had silently not persisted on save — re-entered it and retested.
6. 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