I’ve only just gotten started, and don’t have my system fully working yet, but when I was trying to get LDAP user authentication working, I noticed a limitation. The server does not seem to be able to authenticate using credentials of its own, and instead relies on querying the LDAP server anonymously. This is a problem for me (and I suspect others?) who severely restrict what resources anonymous users have access to on our LDAP servers. Binding as a user allows us to give services the permissions they need to properly authenticate users without exposing that information publicly.
It would also be beneficial if some information about the current LDAP settings could be added to the administration manual, since the current system seems unintuitive to me, especially as it relates to user permissions.
Ah, I see. That’d be part of my problem then, since I’m coming from the LDAP side rather than the AD side. I did see that it was marked as experimental, but I try to use LDAP authentication whenever possible because single sign on is nice. I absolutely understand if LDAP isn’t a priority for you, I have no idea how many people actually use it.
If you’re still interested though, even with the server binding as the user it’s trying to log in as, that still only works if the username you expect people to log in as is the same thing as their distinguished name (or, at least the value of the attribute that is their distinguished name). In my case and I suspect other cases, the distinguished name has nothing to do with the name the username, which means the server needs to query other values for the username in order to extract the distinguished name.
I don’t have a curl command on hand for what this looks like, but I do have an ldapsearch command from a script that does this:
ldapsearch -o nettimeout="$TIMEOUT" -H “$SERVER” -x -LLL -D “$SERVER_USER” -w “$SERVER_PASS” -s “$SCOPE” -b “$BASEUSERDN” “(displayName=$(ldap_dn_escape “$username”))” dn | sed -n ‘s/^[ \t]dn:[ \t](.*)/\1/p’)
Sorry, that’s probably no great help, but it’s all I have on hand.
Additionally, I’m still unclear on how the permissions allocations are handled for LDAP/AD users?
I am using AD bindings but in the setting “LDAP/AD Group and Class Query” you can define what attribute is used to compare username. In my case (and also the standard case I guess) this is defined as:
Here you can simply change “sAMAccountName” to whatever you want the username to be queried from.
I have not researched permission definition deeply but I guess with “LDAP/AD Group permission mapping” you should be able to give particular LDAP groups the permission to use Urbackup features. As there is no documentation available I am unsure about possible rights here. I am using “all” right for Domain Admins in my case.
Yeah, I saw that. My problem is that unauthenticated users can’t run searches (because I’ve disabled anonymous binds), but you can’t bind based on the username, because it’s not in the distinguished name of the account. The server would need to be logged in in order to run the search to translate the username into a distinguished name to authenticate against.
Essentially I’d have to completely rearchitect my directory to accommodate this configuration, which is impractical at this time. I’ll just have to use the built in accounts system, and if LDAP support gets some love in a future update, I can switch over then.