惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
MyScale Blog
MyScale Blog
博客园 - Franky
The Cloudflare Blog
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
博客园 - 聂微东
WordPress大学
WordPress大学
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
T
The Blog of Author Tim Ferriss
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
罗磊的独立博客
Google DeepMind News
Google DeepMind News
P
Proofpoint News Feed
Martin Fowler
Martin Fowler
aimingoo的专栏
aimingoo的专栏
J
Java Code Geeks
腾讯CDC
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
G
Google Developers Blog
博客园 - 【当耐特】
美团技术团队
云风的 BLOG
云风的 BLOG

Proxmox Support Forum

[SOLVED] - Github Auth for Mirrors-Kernel Repo? [Automation] Mass migration tool for MS Win11/Server Proxmox GUI hang - not response is it possible to reject or quarantine spam based on conditions I set ? The PVENode task list in PVE9 is partially obscured due to the terminal font being too large. About 100% error reporting due to pveproxy.service hooks Kubernetes overlay networking breaks when upgrading from PVE 9.1 to PVE 9.2.3 Zentraler Speicher No space left on device Combine datastore and direct file archival to tape Kernel panic VFS: Unable to mount root fs on unknown-block (0,0) sobald ein 7.x Kernel verwendet wird. How to migrate disk of a VM from one ZFS to another Windows Server 2025 fails to boot after PVE 9.2 / Linux 7.0 Kernel upgrade Cannot Install Proxmox on T610 Poweredge with H700 PERC card sdn Config. gateway not reachable How to safely change domain/FQDN? Welche Filterquote erreicht ihr? NFS Share status unknown on 2 of 5 nodes Can't connect to PVE9 consoles [solved] Can't connect to PVE9 consoles [solved] [SOLVED] - Use secondary network for PVE commands Created cluster, one node storage gone BUG: proxmox mail gateway FROM = null bypass spam filtering Moving existing PBS from VMWare workstation to PVE cluster Does eBGP SDN fabric support external peering? Bug: PDM 1.1 not recognizing valid license status Proxmox GUI hang - not response PVE crashes unexpectedly Proxmox Backup Server 4.2 released! Advice
PDM 1.1.1 unable to add AD realm with anonymous search
invalid@exam · 2026-05-29 · via Proxmox Support Forum

Hi,

trying to add AD realm with anonymous search (without bind user):

Code:

api error (status = 400: Could not search LDAP realm, base_dn could be incorrect: LDAP operation result: rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication": rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication")

The same setup works for PVE 9.1.1 (without bind user):

Code:

ad: SUB.EXAMPLE.ORG
        comment AD authentication
        domain sub.example.org
        server1 FQDN1
        base_dn DC=sub,DC=example,DC=org
        case-sensitive 1
        default 1
        mode ldaps
        server2 FQDN2

The optical difference is missing field "domain" (aka base_dn) in PDM GUI.

Interesting that the error here is about missing authentication, are you sure that both address the same AD realm from the same network?

The PDM (and PBS) implementations of our AD realm support try to guess the base-dn parameter from the default naming context that your AD realm uses. If this doesn't match the actual base-dn you want to use this won't work. For now, you should be able to add the realm manually by adding the following to the file /etc/proxmox-datacenter-manager/access/domains.cfg:

Code:

ad: SUB.EXAMPLE.ORG
    base-dn DC=sub,DC=examplae,DC=org
    mode ldaps
    server1 FQDN1
    server2 FQDN2
    comment AD authentication

Note that there is no support for case insensitivity for AD/LDAP realms in PDM/PBS yet.

Adding domains.cfg with "base-dn" works. But with "base_dn" don't:

Code:

api error (status = 400: parsing "/etc/proxmox-datacenter-manager/access/domains.cfg" failed: line 2 - unknown property 'base_dn')

The returned error in the first post use "base_dn".

Next, in the "Sync options", when trying to change anything, "Update" button generate the same error with "base_dn":

Code:

api error (status = 400: Could not search LDAP realm, base_dn could be incorrect: LDAP operation result: rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication": rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication")

Maybe "base-dn" and "base_dn" mistake in code?

Adding AD realm with sub.example.org generate the same error as in the first post, so case insentivity don't matter there now.

Plus, when adding user with AD realm, it requires password in the input fields.

The returned error in the first post use "base_dn".

Yes, due to naming conventions base_dn is used in our Rust code base, but the configuration expects base-dn. I understand this is confusing, though. In the configuration you should use base-dn.

Next, in the "Sync options", when trying to change anything, "Update" button generate the same error with "base_dn":

Yes, every time you try to update something, PDM will try to use the new configuration to query the AD realm. If that doesn't work out, it refuses to update the configuration. This is intended to act as validation for the provided configuration.

Adding AD realm with sub.example.org generate the same error as in the first post, so case insentivity don't matter there now.

Alright, thanks for testing that. Though the capitalization will also matter once we get this to work.

Neither PBS nor PDM allow you to set a base-dn in the UI at all. Instead, they try to ask the AD realm itself for its “default naming context”. If the base-dn isn't the default naming context, you will get the above error. I am currently working on a patch already that should improve the behaviour here. Can you test the following still, though: If you add the realm manually by adding it into the domains.cfg, as outlined above, and try to do a sync (ideally with “Preview only” enabled), what error do you get?

With manual "base-dn" configuration and any change in the "Sync Options"

Code:

api error (status = 400: Could not search LDAP realm, base_dn could be incorrect: LDAP operation result: rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication": rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication")

Btw, i don't se any "Preview only" element.

Last edited:

Are you triggering that error by editing the realm through the UI? Please don't edit the realm through the UI. Instead, add the realm as intended to the file /etc/proxmox-datacenter-manager/access/domains.cfg. Then use the “Sync” Button in the UI under Configuration > Access Control > Realms. A dialog should open and there you should see a checkbox with the label “Preview Only”.

00002020: Operation unavailable without authentication

This still indicates that you do need to be authenticated to use this AD realm. So are you sure this exact AD realm can be used without a bind domain name and password?

AD realm is created manually in domains.cfg. This works
Editing via gui "Sync options" failing.
"Sync" via gui Realms failing - unedited error message:

Code:

2025-12-10T10:53:48+01:00: this is a DRY RUN - changes will not be persisted
2025-12-10T10:53:48+01:00: TASK ERROR: LDAP operation result: rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication": rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication"

And maybe one missed info before:
Plus, when adding user with AD realm via GUI, it requires password in the input fields.

Maybe there is information mismatch. I want to use AD login as on the PVE (users without entering password created manually, not synced), nothing more now. So yes, our AD maybe require login for any other non-login task.

"Sync" via gui Realms failing - unedited error message:

Alright, that means for the settings you are providing your AD realm expects some kind of authentication:

00002020: Operation unavailable without authentication

Can you tell me the differences between your PVE and PDM AD realm exactly?

Plus, when adding user with AD realm via GUI, it requires password in the input fields.

Yes, currently a bind-dn is only supported in combination with a bind password. Are you using a bind-dn in Proxmox VE?

PVE (9.1.1):

Code:

domains.cfg:
ad: SUB.EXAMPLE.ORG
        comment AD authentication
        domain sub.example.org
        server1 fqdn1
        base_dn DC=sub,DC=example,DC=org
        case-sensitive 1
        default 1
        mode ldaps
        server2 fqdn2

user.cfg:
user:someuser@SUB.EXAMPLE.ORG:1:0:Firstname:LastName::::
group:administrators:someuser@SUB.EXAMPLE.ORG::

PDM:

Code:

domains.cfg
SUB.EXAMPLE.ORG
    base-dn dc=sub,dc=example,dc=org
    mode ldaps
    server1 fqdn1
    server2 fqdn2
    comment AD authentication

I don't use binding user on PVE.

Note that there is no support for case insensitivity for AD/LDAP realms in PDM/PBS yet.

Hi, is there some timeline for that? we have a lot of users from AD with different cases and we starting using PDM now.

Last edited:

PDM 1.1.1 tests (based on "Allow changing an LDAP realm to use anonymous search."):

Code:

domains.cfg:
ad: sub.example.org
    base-dn dc=sub,dc=example,dc=org
    mode ldaps
    server1 fqdn1
    server2 fqdn2
    comment AD authentication

user.cfg:
user: USER@sub.example.org
enable true

Code:

2026-05-29T09:38:43+02:00: authentication failure; rhost=[IPV6]:28810 user=USER@sub.example.org msg=LDAP operation result: rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication"

Login via gui:

Code:

Login failed. Please try again (api error (status=401; Unauthorized))

And adding AD realm via gui:

Code:

"api error (status = 400: Could not search LDAP realm, base_dn could be incorrect: LDAP operation result: rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication": rc=1 (operationsError), dn: "", text: "00002020: Operation unavailable without authentication")"

Another bug - when you remove REALM with users mapped, and after it try to remove user:

Code:

api error (status = 400: unknown realm sub.example.org)

Removing user fails.

Thanks for the notice, I'll see if I can take another look there. Sorry for the inconvenience.