Hi Bocsa,
If you are mapping some users, but not all, could it be that those users are from specific AD group that's not mapped properly?
show user group-mapping state <value>|<all> show user group-mapping statistics
If that's not the case, can you check logs for that particular user (that is not mapped) on all three servers? Could they be mis-matching? Silly question, but also - are your clocks all the same on servers (do they have same NTP server and are they all updating clock properly?) Reason why I ask is that sometimes, when user mappings are shared between servers but one of them has clock that is slightly off, that can produce unwanted results as it depends what logs are parsed last and what was the event.
If possible, I would also try to simply use only one of three servers temporarily (and test all of them separately, one by one) to see if I will have any missing users when mapping from a single server, that might be faster than looking through the logs of all three servers.
If that is not the case either, and you cannot find much in the logs on the server side, try raising debug level on the user-id daemon; by default it is on info level. From cli, you can set:
debug user-id on dump
run your diagnostics (get problematic user to log on and log off) and than review logs for that username:
less mp-log useridd.log
When "inside" the log, you can use commands from linux's less command - use / to search for username, etc...
once you are done, re-set debug level for user-id by doing:
debug user-id on info
debug user-id get
Last, but not the least - what is the uptime of your device? (you can see that from "show system info" in cli). There was a bug where UserID stopped working after 388 days, but that has been fixed long ago, applies only if you are running an old release. If this is the case, simply restart UserID daemon 🙂
If nothing from above helps.... let us know or reach out to TAC and inform them what have you done already to diagnose this 🙂
Best regards,
Luciano
... View more