0

I'm setting up a Debian server in my company where users are managed in an Active Directory.

I'd like to authenticate users with AD but I'm thinking it would be better, if feasible, to have a local OpenLDAP to authenticate against in case AD server or network falls.

I've seen tutorials about setting up pass-through authentication

but it doesn't say what happens if the AD server is not reachable. AFAIU, the request fails.

Someone here suggest using OpenLDAP Proxy Cache Engine setting a high TTL.

Should I be replicating the whole directory instead ? I don't mind if new users can"t be authenticated. I'd be happy if already locally known users can be authenticated using the last accepted password. So the easiest solution is my favorite.

I searched with a lot of terms including cache/caching, replica, etc. I didn't find any "grab-my-hand-and-show-me-how-to-do-that-on-debian-jessie" step-by-step solution, so it could be that what I thought would be relatively standard is in fact a bit tricky.

Improve this question

2 Answers 2

Reset to default
1

I'm not sure whether you're asking about generally how to have a Debian server do authentication/authorization against Active Directory...or how to make sure the existing authentication/authorization is highly available. I'm going to assume the latter in this answer.

The short answer is that setting up OpenLDAP as a cacheing layer for an Active Directory is silly. AD is a multi-master replicated database. If you need high availability, just bring up another. If your DCs are in a different network segment that you're worried about losing connectivity to, bring up a DC (or two) in your local network segment and setup the necessary site topology in AD.

Improve this answer
2
  • I want the credentials synced from AD but I'd be happy if the setup could run even if AD falls or is unreachable. The AD, like most MS stuff, is managed by our IT contractors and we won't have it redunded, so I guess I'll just rely on it and the AD authenticated services on my server will be down when the AD is down, which should not be often anyway. I just thought/hoped there might be an easy way to be more "independent".
    – Jérôme
    Jul 6, 2015 at 19:34
  • I should add that "setting up OpenLDAP as a cacheing layer for an Active Directory is silly" is actually the kind of answer I'm looking for. When I think my setup and my need/wish are pretty common and I can't find any detailed explanation/tutorial, I tend to conclude that I'm not looking in the right direction at all. I'm not asking for a twisted way to accomplish what I was trying to but for a pointer to what I should be doing.
    – Jérôme
    Jul 6, 2015 at 21:43
0

A local OpenLDAP server is probably not the best way to handle the situation described. I think you should take a good long look at sssd. It should have everything you need.

Improve this answer
3
  • Does this imply having all the users managed as system users, as in AD domain integration? One of the services I'm thinking of is Redmine. I can authenticate to it only through LDAP (or by creating users manually...). Are you suggesting I could do something like this : AD -> sssd -> LDAP -> Redmine? Integrating the machine to the domain (with all users as system users, AFAIU) seemed overkill but there are so many config possibilities and I'm probably missing basic knowledge. If it takes too much expertise, I should probably stick to AD only authentication and cope with potential downtimes.
    – Jérôme
    Jul 6, 2015 at 19:45
  • @Jérôme Perhaps what you're missing is that AD provides LDAP all by itself?
    – 84104
    Jul 6, 2015 at 20:35
  • Yes, I know that. I managed to have Redmine use AD as LDAP. Except it does no caching. And even if it did, other services might not. Starting from there, I thought I might as well authenticate to a local LDAP that would do the caching, but from what I understand in the answers here, this is not the best idea.
    – Jérôme
    Jul 6, 2015 at 21:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .