Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 2014-09-17 9:15 GMT+02:00 Rob Verduijn rob.verdu...@gmail.com: 2014-09-16 20:57 GMT+02:00 Nordgren, Bryce L -FS bnordg...@fs.fed.us: Also opened https://fedorahosted.org/freeipa/ticket/4544 Tried to summarize this thread on that ticket. Back to the OP's concern, whenever I use NFS as a documentroot for apache (even a WebDAV server), I make a separate mountpoint, fall back to sec=sys, set all-squash, and specify the webserver's IP. It's not like individual user accounts need a presence on the filesystem. Do you need encryption for your application or is apache just going to spray the content out across the commodity internet via un-encrypted http? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project Hello, I've already implemented the share as 1.2.3.4(ro,sync,all-squash,sec=sys) It's not sensitive data and it's also internal, so it will do fine for now as a workaround. But there is going to be a situation that apache requires access to a document root containing sensitive data, in that case I would prefer a more secure method. I've been reading up a little on the gss-proxy, which would be the prefered way on the obtaining of the credentials from a keytab. Have gss-proxy do it or have gss-proxy use s4u2proxy to fetch the keytab ? (which might also solve some of my ssh anoyances but that's a bit off topic) Rob Verduijn -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
On Saturday, September 20, 2014 12:15:04 PM Simo Sorce wrote: [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. Simo, Rob's [service/nfs-client] configuration looks identical to mine, which appears to be the default, at least in Fedora 20: https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/examples/gssproxy.conf.in -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Or maybe this if you won't mind that any service with a keytab gets nfs access. euid = %U Thanx for the quick help. [gssproxy] [service/nfs-client] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = no trusted = yes euid = 48 2014-09-20 18:15 GMT+02:00 Simo Sorce s...@redhat.com: On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
On Sat, 20 Sep 2014 11:38:16 -0500 Anthony Messina amess...@messinet.com wrote: On Saturday, September 20, 2014 12:15:04 PM Simo Sorce wrote: [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. Simo, Rob's [service/nfs-client] configuration looks identical to mine, which appears to be the default, at least in Fedora 20: https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/examples/gssproxy.conf.in Oh it is and I forgot why we put allow_any_uid in, it's because now rpc.gssd drops privileges before checking ccaches ... doh, I had forgotten. I wonder if we should remove the keytab from the default configuration though ... Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
On Sat, 20 Sep 2014 19:44:28 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. We do not have a lot of docs yet, indeed. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Nope, euid is singlevalued. Or maybe this if you won't mind that any service with a keytab gets nfs access. euid = %U Setting %U in euid does not work, that's why we have allow_any_uid. Thanx for the quick help. Glad you got it working to your liking, and feel free to ask questions directly on the gss-proxy mailing list if you want. Btw in the conf below you can also remove completely the allow_any_uid (no is the default) and the trusted options (you should not really trust apache to impersonate any user, w/o trusted it will just be itself). Simo. [gssproxy] [service/nfs-client] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = no trusted = yes euid = 48 2014-09-20 18:15 GMT+02:00 Simo Sorce s...@redhat.com: On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA ActiveDirectory Integration: Managing AD Users in IPA
(belated response) On Sun, Sep 14, 2014 at 12:10 AM, Dmitri Pal d...@redhat.com wrote: On 09/13/2014 04:03 PM, Traiano Welcome wrote: Hi List Currently I have a stable trust relationship going between IPA and Windows AD. I create users and manage passwords in AD, but want to manage the rest in IPA, the rest being default shell, default home directory settings, RBAC, HBAC, Selinux etc .. What I'm expecting it to be able to log into the FreeIPA web interface, and see a synched list of users created in AD appear in the interface, after which I can modify the settings on a per user basis. If that level of granularity is not possible, I would then expect to be able to at least apply an IPA-imposed set of account defaults on and AD user group: - default shell - HBAC rules - Sudo rules - SELinux rules - RBAC Is this possible with FreeIPA? I can't find anything coherent in the documentation that describes an effective way of managing the POSIX attributes of AD users in FreeIPA. Thanks in advance! Traiano You are to some extent describing a feature that we call views that is currently in works. But there are two parts: a) Ability to overwrite POSIX attributes for AD users - this is views https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/4509 This is exactly the feature I had in mind! b) Ability to apply policies to AD users. It is already possible. This is done via group membership. So you create a group in IPA, make AD group an external member of that group and then use that IPA group to apply HBAC, SUDO and SELinux rules. For the interim, this seems to meet the need. Seems to work reliably in tests as long as one keeps a spreadsheet of AD group mappings to IdM user rights. Requires some coordination with the local AD administrator :-) As for RBAC what do you mean? By RBAC, I mean to define linux server user roles with a certain profile of sudo rights, selinux policies and host access rules which one could apply to individual users without grouping them. Although, conceptually it appears that there's little difference in using user groups to represent the same type of container as a role would. However, I suppose the user groups mechanism essentially achieves the same objective. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
