User talk:Stewbond
Hi Stewbond,
I'm also interested in resolving the LDAP page problems. Would you join me in this side quest? I'm considering merging OpenLDAP and LDAP authentication in one single LDAP page. What do you think ? We can start with a review of available LDAP software and then describe specific details about the openLDAP configuration.
We should also consider deleting the LDAP hosts page as it is very outdated or warning the reader that there are other (simpler and more efficient) ways to centralize the hosts file information.
Dccafe (talk) 13:50, 1 February 2017 (UTC)
Stewbond (talk) 18:29, 1 February 2017 (UTC)
Hi Dccafe,
I have a few new computers arriving this week and am setting up an office. My interests don't extend too far past getting a working setup for the office, and I don't have much expertise beyond the past few weeks of reseach and trials in an virtual machine environment. Therefore I may not be much help.
The success that I had experienced comes from: https://onemoretech.wordpress.com/2014/02/23/sssd-for-ldap-auth-on-linux/
In an amazing turn of events, this redhat/fedora package referenced in the above link is available here: https://aur.archlinux.org/packages/authconfig/
I wrote a markdown document describing my client solution below. I'm going to finalize it next week when I complete the configuration of my client PCs. I also still need to complete the LDAP server configuration and I'll be documenting my experience in setting up that server too. I'll be happy to send you the markdown documents that will reprensent my company's internal documentation. I plan to document this in a very "from the ground up" series with every command needed to get from a fresh install with only a root account to an LDAP client in my specific configuration.
LDAP has a lot of configurations. To me, the most useful part of this page will be instructions for individuals who want to install Arch at work and authenticate against their organization's LDAP server. The next most important section would be instructions for creating an LDAP server to authenticate client accounts with. I think those are the use cases that we should concentrate on, then handle the delta for each additional use case.
The LDAP server should certainly be documented ahead of any LDAP clients (because it needs to be set up first), but I think it's imporant to avoid the assumption that the server and client will be on the same machine as the current page seems to suggest most of the time.
I believe your case is very similar to mine. I've built, in the beggining of the year, a lab with 10 computers and a server. I have a centralized server where my LDAP server is running together with a NFS server for my users home directory. It is basically a research and education facility, so there's a lot of recycling when it comes to human resources. My goal was to make the administration of users, groups, quota, ssh keys, very human friendly. This I have accomplished with a LDAP configuration website provided by the ldap-account-manager package (aur). I find it to be more user-friendly than the recomended phpLDAPadmin.
I must thank you for sharing the link about sssd configuration and authconfig package. It looks very promising indeed. I'll test on my machines and report back.
About the wiki...
I believe the user name suggested by the wiki for the "root" user is somehow missleading. I rather use a different name to clearly distinguish local root user from the ldap administrator. I prefer something like admin, manager or administrator. What do you think?
Also, we should encourage the use of sssd over traditional pam_ldap. I'll try to get things working properly on my machines before writing anything.
I do agreed with you about separating and making it very clear that the server configuration is done on a different machine than the client configuration. It could be done on the same machine, but let's not make that the default assumption as it is now.