[clue] Filesystems + LDAP permissions???

[Raymond DeRoo]

Not so sure my reply will be helpful. But I have never worked on a system configured in the fashion you are trying to do. Typically LDAP needs to map to some “local” UID/GID for users to have functional login rights. In a past life, I accomplished this by using LDAP for the authentication, and puppet (now Ansible) to manage which accounts should be on which hosts (physical and virtual). In the end, if files are being stored on linux, we are still limited to user/group/world permission system. If the goal is to get something more fine grained (and I don’t care what anyone says, I’m no Windows lover myself, but Microsoft got file permissioning right with NTFS) then Linux is not proper solution for complex file permission storage.

Personally, I cannot envision any way that LDAP is a single source solution. That being said, I would love to hear about whatever solution you do come up with.

Kind regards,
Raymond


> On Sep 13, 2016, at 11:16 PM, foo7775 at comcast.net wrote:
> 
> Hi all,
> 
>   I've been asked to create a small directory structure & apply permissions to it using LDAP user accounts rather than the "normal" local Linux UID/GID permissions.  (My guess is that this may be a test run for a larger effort that will span several servers if successful.)
> 
>   As requested, I have created the directory structure, added 'ldap' to the nsswitch.conf file, & created the test user accounts/groups in LDAP by using a .ldif file - but at this point, I'm stuck.  I really have no idea how to "make the connection/association" between the filesystem structure & the LDAP UIDs/GIDs.  I have google'd until my eyes have crossed, I've studied LDAP & I'm reasonably comfortable (at least in *THEORY*) with writing the ACLs in LDAP - but I haven't seemed to find anything that tells me how to connect the two "subsystems".  I may be over-thinking it, but I don't know.  The OS is RHEL 6.x.
> 
>   I'd *sure* be grateful for any help that some kind soul could provide...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20160914/35ca0f19/attachment.html