Finding and thoughts on LDAP (Support for Master-Slave)

[christian]

But understand I am the Senior Security Technical person for a 100,000+ user federal government organization....  so my priorities are sort of biased.

Working as an enterprise IT architect for big company (around 60,000+ users), I also tend to have biased view 
For the time being, I would not suggest eBox as component anywhere in my company.

From my standpoint, eBox targetting (againg that's only my personal view) small/medium business and soho, high availability is not something having top priority.
I don't don't mean it's not important but I would not put it on top of the list of "missing" features.

What's critical for such component is security, stability and easiness in term of deployemnt and administration.
1 - Security when eBox is used as internet gateway.
2 - Easyness, because security depends on it (what's difficult here is to "hide" complexity and make it easy to understand and configure so that it remains safe)
3 - stability would be my third topic in the stack.

Of course what is supposed to work "must" work: I would prefer not to have "not fully functional" LDAP master/slave feature but have capability to use "external" ldap server. What if you can't change ldap content for some time in small/medium business environnement? Do you really need multi-master?

I share previous comment regarding HA: the one that is required if any is WAN service.
Then for small/medium business, providing strong reliable data backup/restore is more critical than HA.
When it comes to provide HA for file sharing, access to mailbox etc, it's far beyond what this kind of "appliance" can bring out of the box.

This would require external storage (SAN or NAS) + either cluster or load balanced services...  much more complex than RAID of your choice for local storage and strong backup process and definitely, again for what I feel, out of the scope of such solution.

To make a long email short, what I would see as "ideal" design for small/medium business, using 2 or 3 eBox is:
eBox 1 - internal server running LDAP, Samba, MDA (means POP or IMAP). i.e any user oriented service.
eBox 2 - internet gateway services (WAN, proxy, MTA + anti-virus). No user mailbox here. (i.e. no data except what is exposed by HTTP/FTP service if any. mail are delivered to eBox 1.
eBox 2 should be configured either to used local slave LDAP or to rely on LDAP  on eBox 1, or both as it's the way LDAP service handles failover as defined in LDAP RFCs.

Yes, there is a lot of SPOF with such design :-) but it's simple and safe.
If you feel you need more availability, then it's no more, to me, the same game as it requires different adminsitration skill. Not the same cost 

[Saturn2888]

FreeNAS LDAP is broken. Until someone shows me it works, it's broken. I enabled AD in FreeNAS and that got the users from eBox, but it did not allow access. If all you want is a NAS, you really should use FreeNAS since ZFS is always gonna be better than EXT3 in the long run. philmills, do you want me to show you a picture of File Sharing (samba) working on my slave?

[poundjd]

Christan,
   You have convinced me. HA for the SMB is less important than all of the issues you raised...  (* But I still want it!!!!  *).
-jeff

[alvinquah]

Of course what is supposed to work "must" work: I would prefer not to have "not fully functional" LDAP master/slave feature but have capability to use "external" ldap server. What if you can't change ldap content for some time in small/medium business environnement? Do you really need multi-master?

To make a long email short, what I would see as "ideal" design for small/medium business, using 2 or 3 eBox is:
eBox 1 - internal server running LDAP, Samba, MDA (means POP or IMAP). i.e any user oriented service.
eBox 2 - internet gateway services (WAN, proxy, MTA + anti-virus). No user mailbox here. (i.e. no data except what is exposed by HTTP/FTP service if any. mail are delivered to eBox 1.
eBox 2 should be configured either to used local slave LDAP or to rely on LDAP  on eBox 1, or both as it's the way LDAP service handles failover as defined in LDAP RFCs.

My sentiment with Christian. I am confident of pushing eBox into the SMB segment around my region. I agree that eBox should be split into different roles onto different hardware for the best practice in deployment. But considering that SMB generally do not want to spend so much on hardware, they will want to have a functions packed into a box. Of course, if we take this scenario, then it will be very awkward;

"Customer A has deployed first server with all modules installed. They have installed master/slave and other userandgroup dependent modules such as mail. They are satifsfied and next, they want to perform a pilot test on VOIP module and decided to bring it live.

Suddenly, there comes a day where eBox hardware malfunction and the users cannot login their profile with all the share folder and roaming profiles. As a partner, we can of course propose slave server for redundancy. But because of the restriction we are unable to further upsell another eBox for deployment."

[christian]

Do not misunderstand my point. I'm not stating that LDAP HA is not required. I'm stating that master/master is not required for SMB. master/slave is enough... but that's not what I feel to be the main point.

Alvinquah,

What you describe is indeed critical and will have major impact, whatever company size.
I fully share but will not make conclusion that master/salve (i.e. LDAP) is "THE" blocking point here.

Today components are configured to use "local" LDAP server and this results in some impossible design due to technical constraint because master LDAP does not fit with some modules.

If you look at it in a slightly different way and deploy somewhere a couple of master/master or master/slave LDAP servers, providing nothing more than highly avalaible LDAP service and then configure all eBox components to rely on these 2 LDAP servers in a failover mode, then authentication and profiling (e.g. group memebrship) is no more an issue.

This approach is very common in companies heavily relying on LDAP. In my own company, we have about 80 LDAP servers world wide, in master/slave mode for a lot of services and I can tell you LDAP is not the spof (I know it quite well as I designed this part of the infrastructure  years ago )

We are not yet at this stage with current eBox version. One of the reason, f.i., is that it would mean that mail backbone is able to rely on external LDAP service to identify where mail should be delivered per user.

Back to your point, once you have this HA LDAP service, you're still facing same issue that is to provide Windows profile, share folders etc...   Redundant "Samda" DC should not be a big issue.
Redundant "Samba" file server is less obvious, again for small/medium business.

From a technical standpoint, I'm pretty sure I'm not totally wrong for what concerns the LDAP design. Then drawback of what I explain is that it makes deployment less straighforward and requires deeper technical understanding.
Where is the balance between very simple but not so flexible and very flexible but not that simple?
On the other hand, it makes room for some service isn't it?

Definitely I would, if I was in charge of eBox evolution, push in this direction that is to make each and every component relying on LDAP able to use external LDAP service, configuring potentially 2 ldap servers in failover mode. This doesn't prevent to configure local server  but that's the first step toward HA.

Sorry for this long email but there is another point I'd like to comment: SMB don't like to spend much on hardware.  I do share!
At home I've deployed 2 eBox platforms, one as internet gateway (Atom 330) and one as NAS (another Atom 330 from TranquilPC) and for less than $1K, I've an infrastructure that would fit for a lot of small business. Cheap but still I would like it secure, not having master LDAP and users mailboxes on internet gateway box.

Cheers.

[philmills]

philmills, do you want me to show you a picture of File Sharing (samba) working on my slave?

Not really, since Isaac already responded in the other thread recognising this as an issue. Fact is that if you follow the instructions it doesn't work. Weird hacks and workarounds don't cut it for me in a supposedly stable release...

Am interested to know though if you're just filesharing or using domain logons too, and if so are the fileshares full read-writable to logged on users?
I can get fileshares to work, i just can't add admins to them, which renders them pretty useless for me...

[Saturn2888]

I haven't tested it much. I had messed around with a laptop doing domain authentication, got that to work, and was able to access the shares. This machine was authenticating to the WINS server which is also the slave in my master/slave configuration. It's the gateway, DHCP server, and DNS server for the network. I guess I could try to access the shares on the master. I've done that without domain authentication no problem, haven't tried it once authenticated.

[poundjd]

Guys,
     What package are we using for the LDAP functionality?  OpenLDAP? or something else?
-jeff

[Saturn2888]

OpenLDAP with Slapd.

[poundjd]

Saturn2888,
     Thanks,
-jeff

[alvinquah]

Do not misunderstand my point. I'm not stating that LDAP HA is not required. I'm stating that master/master is not required for SMB. master/slave is enough... but that's not what I feel to be the main point.

Alvinquah,

Back to your point, once you have this HA LDAP service, you're still facing same issue that is to provide Windows profile, share folders etc...   Redundant "Samda" DC should not be a big issue.
Redundant "Samba" file server is less obvious, again for small/medium business.

From a technical standpoint, I'm pretty sure I'm not totally wrong for what concerns the LDAP design. Then drawback of what I explain is that it makes deployment less straighforward and requires deeper technical understanding.
Where is the balance between very simple but not so flexible and very flexible but not that simple?
On the other hand, it makes room for some service isn't it?

Definitely I would, if I was in charge of eBox evolution, push in this direction that is to make each and every component relying on LDAP able to use external LDAP service, configuring potentially 2 ldap servers in failover mode. This doesn't prevent to configure local server  but that's the first step toward HA.

Cheers.

Totally agreed. I will say let eBox developers come up with the stability of all the great features that  are available in eBox Platform. The concern coming from the customers should not be the technical issues if we know how eBox should be deployed but rather the features and cost reduction they can get when they use eBox in their environment.

[nachico]

Really interesting topic! I will comment on those posts concerning roadmap and priorities, and leave the topic of revenue model for a different board (there is a whole category in the forum to discuss on services and revenue).

First, thank you for your suggestions. It was really interesting to read all the different opinions on what should be our roadmap for the development of eBox. I agree that at this moment we should focus on completing current functionality and improving stability, usability and disaster recovery. In fact, that is the main focus at this moment. And with the migration to Lucid there is not much space for new modules.

However, we should not stop completely from adding new functionality. It takes several iterations to have a new functionality complete, useful, intuitive and stable. So that's why we are starting to work in HA, as it will not be easy to include it in eBox while maintaining its focus as an integrated server for SMBs. Master-Slave is the first step in that direction but there is still a long road ahead