Hi @mramos17 – sorry for the slow reply, and sorry you’ve spent two days on this with nothing in the logs to work from. That second part isn’t your fault, and it’s the key to the whole thing, so let me start there.
PiKVM’s LDAP plugin reads exactly six settings and silently ignores everything else. (Unknown keys produce no error and no log line at all – that part is genuinely invisible. Authentication failures do log, though, and I’ll come back to that at the end.) The config loader walks its own list of known options and picks those out of your file – it never looks at the keys you actually wrote. So an option it doesn’t recognise isn’t reported as an error, it’s simply never read. Nothing is logged, because nothing in the code ever sees it.
The six it reads are:
url verify base
group user_domain timeout
Would you mind comparing your override.yaml against that list? Several of the settings in your screenshot don’t appear to be on it – and if that’s right, they’re being discarded silently, which would explain why changing them has had no effect for two days. Worth checking spelling carefully too: a key with a space where an underscore belongs is still valid YAML, so it loads cleanly and then does nothing.
I should be straight with you about how confident I am here. What I’m sure of is how the plugin behaves – that’s from the source and the docs. What I’m guessing is that it’s what’s biting you, and I’m guessing it from a photo, on a kvmd I don’t know the version of. So treat the above as a strong suspicion rather than a diagnosis, and let’s confirm it rather than assume it. Which brings me to the useful part.
There’s one structural thing I’d flag before you retry, because it changes your setup rather than just your syntax: PiKVM binds to AD as the user who is logging in, not as a service account. It builds username@user_domain and binds with the credentials the person typed at the prompt. There’s no service-account bind anywhere in the plugin – so the account you created for it isn’t being used, and user_domain has to be set or the bind goes out as a bare username, which AD will refuse. That failure looks exactly like what you’re describing.
One more that catches people with tidy AD: authorisation is a single, direct memberOf check against the one group you name – nested groups don’t work. If your users are members of a group that’s nested inside the group you’ve specified, they won’t authorize. They have to be direct members of that exact group DN.
The documentation for all of this is here, and it has a complete working example you can copy:
That page is easy to miss – the main authentication page only links to it in passing, which I suspect is how you ended up building the config by hand. We’ll look at making that signposting better.
Two more things that will cut this short.
I can’t see a group setting in your screenshot – it may simply be cropped, since the right-hand side is cut off. But if it’s genuinely absent, that alone would stop the block working: it has no usable default and an empty value fails validation. Same for user_domain, for the reason above.
And your logs will tell us exactly where it’s failing, which saves guessing. kvmd logs a different line depending on the stage:
Got access denied for user ... by TOTP – the two-factor check, nothing to do with LDAPGot access denied for user ... from auth service 'ldap' – it reached AD and AD said no- neither line – it never got as far as authenticating
That first one is worth checking even though you haven’t mentioned 2FA. If /etc/kvmd/totp.secret exists and has anything in it, kvmd takes the last six characters of whatever you type in the password box as your 2FA code and strips them before authenticating – there’s no separate code field. So with 2FA on, an AD password typed normally arrives at AD six characters short and gets rejected. It’s off by default, but it’s a one-line check and it would look exactly like what you’re seeing.
Here’s how to pull that out. First, check whether 2FA is even on – this prints a byte count, not the secret itself:
wc -c /etc/kvmd/totp.secret 2>/dev/null || echo "no file - 2FA is off"
If that’s missing or 0, 2FA isn’t in play and you can ignore it. (Don’t paste the contents of that file anywhere, including here.)
Then watch kvmd while you make a login attempt. Run this, leave it running, and try to log in from another window:
journalctl -u kvmd -f --no-pager | grep --line-buffered -iE 'totp|auth service|access denied|authorized user'
The --line-buffered matters – without it grep holds output in a buffer and the follow looks like it’s showing nothing.
If you’d rather look at what’s already happened:
journalctl -u kvmd --since '15 min ago' --no-pager | grep -iE 'totp|auth service|access denied|authorized user'
If either command prints nothing at all, run it again without the grep part – journalctl -u kvmd -n 50 --no-pager. Empty output from the filtered version could mean “no auth attempts were logged”, but it could equally mean the service is named something else on your build or isn’t logging where I think it is. Seeing the raw output tells you which, and saves you trusting a silence that doesn’t mean what it looks like.
What you’re looking for is one of these – the exact wording may differ a little on your build, which is why the filter above is deliberately broad:
| line |
what it means |
something mentioning TOTP |
2FA stripped six characters off your password; AD never saw the real one |
access denied ... auth service 'ldap' |
it reached AD and AD rejected the bind |
Authorized user ... auth service 'ldap' |
it worked |
| nothing at all |
it never got as far as authenticating – usually config |
Also, please send pacman -Q kvmd – I’d like to know which version you’re on rather than assume. That matters more than it sounds: the auth logging was reworked upstream in early 2025, so on an older build these lines may be worded differently or be absent entirely. Everything I’ve said about the six settings has been stable for years, but the log wording has not, and I’d rather tell you that than have you conclude nothing is being logged when it’s just phrased differently.
Paste whichever log line you get (redact the username if you like) along with your updated config, and I’ll take it from there. That one line tells us whether we’re debugging your config, your 2FA, or AD itself – which is the question we can’t answer from here.
