You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Jeffrey E Rodriguez (JIRA)" <ji...@apache.org> on 2016/08/12 16:54:21 UTC
[jira] [Comment Edited] (KNOX-537) Linux PAM Authentication
Provider
[ https://issues.apache.org/jira/browse/KNOX-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419103#comment-15419103 ]
Jeffrey E Rodriguez edited comment on KNOX-537 at 8/12/16 4:53 PM:
--------------------------------------------------------------------
I am glad to see Henning's contribution.
Once thing I can suggest for "test an authentication on my mac" is to try with the PAM service files or /etc/pam.d/login or /etc/pamd.d/sshd . On my initial testing I did use those to check Knox/PAM on my mac too.
Here some doc:
First, make sure user accounts on your cluster have the same uid/gid so they are consistent.
Next, for Knox PAM OS authentication on Linux systems you may need to give knox group access to /etc/shadow. This may be challenging since in most Linux systems
like RHEL the /etc/shadow file is owned by root:root and there is no read or write access to it.
Then if using LPDAP PAM authentication you will need to first set Linux authentication using PAM/LDAP. Check Linux Server Hacks volume two
on how to "Authenticate Linux Users with a Windows Domain Controller" and "Updating Client Sytems to User Ldap Authentication". This book
has a lot of valuable information about PAM.
We provide two PAM services examples but if you look at /etc/pam.d you will see many other configuration PAM service files you can
try. The Knox PAM provider parameter main.pamRealm.service will set up the name of the PAM service file from /etc/pam.d to be used.
e.g. We provide a "knoxpamosservice" so you can setup main.pamRealm.service to this name. We can use "knoxpamosservice" PAM service to authenticate against OS (you will need /etc/shadow access as documented above). We should be able to access from your mac by using any of the PAM service files under your mac os /etc/pam.d. ( like "sshd" or "login" ).
Modify your Knox topology file (backup previous version if you are not using Ambari) and replace the authentication ShiroProvider with the
following:
<?xml version="1.0" ?>
<topology>
<gateway>
<provider>
<role>authentication</role>
<name>ShiroProvider</name>
<enabled>true</enabled>
<param>
<name>sessionTimeout</name>
<value>30</value>
</param>
<param>
<name>main.pamRealm</name>
<value>org.apache.hadoop.gateway.shirorealm.KnoxPamRealm</value>
</param>
<param>
<name>main.pamRealm.service</name>
<value>knoxpamosservice</value> </param>
<param>
<name>urls./**</name>
<value>authcBasic</value>
</param>
</provider>
Restart Knox, if you were connected using a browser you may have to restart the browser to flush your cookies. Now you should
be able to user Knox with PAM.
Pam offers a lot of flexibility to Knox users since you now have the freedom to choose what authentication scheme it is to be
used, and also decouples the authentication from Knox runtime. We no longer have to worry about LDAP differences among LDAP
middleware vendors. Most of them would provide a well-documented way to authenticate to Linux/Mac systems through PAM. Knox
can just access the PAM using this Knox PAM provider.
was (Author: jeffreyr97):
I am glad to see Henning's contribution.
Once thing I can suggest for "test an authentication on my mac" is to try with the PAM service files /etc/pam.d/login or /etc/pam.d/login or /etc/pamd.d/sshd. On my initial testing I do use those to check Knox/PAM on my mac too.
Here some doc:
First, make sure user accounts on your cluster have the same uid/gid so they are consistent.
Next, for Knox PAM OS authentication on Linux systems you may need to give knox group access to /etc/shadow. This may be challenging since in most Linux systems
like RHEL the /etc/shadow file is owned by root:root and there is no read or write access to it.
Then if using LPDAP PAM authentication you will need to first set Linux authentication using PAM/LDAP. Check Linux Server Hacks volume two
on how to "Authenticate Linux Users with a Windows Domain Controller" and "Updating Client Sytems to User Ldap Authentication". This book
has a lot of valuable information about PAM.
We provide two PAM services examples but if you look at /etc/pam.d you will see many other configuration PAM service files you can
try. The Knox PAM provider parameter main.pamRealm.service will set up the name of the PAM service file from /etc/pam.d to be used.
e.g. We provide a "knoxpamosservice" so you can setup main.pamRealm.service to this name. We can use "knoxpamosservice" PAM service to authenticate against OS (you will need /etc/shadow access as documented above). We should be able to access from your mac by using any of the PAM service files under your mac os /etc/pam.d. ( like "sshd" or "login" ).
Modify your Knox topology file (backup previous version if you are not using Ambari) and replace the authentication ShiroProvider with the
following:
<?xml version="1.0" ?>
<topology>
<gateway>
<provider>
<role>authentication</role>
<name>ShiroProvider</name>
<enabled>true</enabled>
<param>
<name>sessionTimeout</name>
<value>30</value>
</param>
<param>
<name>main.pamRealm</name>
<value>org.apache.hadoop.gateway.shirorealm.KnoxPamRealm</value>
</param>
<param>
<name>main.pamRealm.service</name>
<value>knoxpamosservice</value> </param>
<param>
<name>urls./**</name>
<value>authcBasic</value>
</param>
</provider>
Restart Knox, if you were connected using a browser you may have to restart the browser to flush your cookies. Now you should
be able to user Knox with PAM.
Pam offers a lot of flexibility to Knox users since you now have the freedom to choose what authentication scheme it is to be
used, and also decouples the authentication from Knox runtime. We no longer have to worry about LDAP differences among LDAP
middleware vendors. Most of them would provide a well-documented way to authenticate to Linux/Mac systems through PAM. Knox
can just access the PAM using this Knox PAM provider.
> Linux PAM Authentication Provider
> ---------------------------------
>
> Key: KNOX-537
> URL: https://issues.apache.org/jira/browse/KNOX-537
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 0.5.0, 0.6.0, 0.7.0
> Environment: All
> Reporter: Jeffrey E Rodriguez
> Assignee: Henning Kropp
> Labels: knox, pam
> Fix For: 0.10.0
>
> Attachments: 0001-knox-537-add-pam-authentication-support.patch, KNOX-537.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> OS level PAM security provides great interface for authentication and authorization. For example, sssd provides support for manage Active Directory nested OU by adjusting ldap_group_nesting_level = 5. Knox configuration is configured to interact with LDAP directly, but this has two short cominges. First, hgh volume traffic is likely to make too many queries to AD without cache. Second, complex logic of LDAP queries can not map correctly to UserDnTemplate without adding more ldap specific logic into JndiLdapRealm code and parameters.
> Knox can be improved to use PAM to out source complex OS to AD interaction to sssd. It is possible to implement a shiro PAM plugin to reduce the complex LDAP logic that is starting to accumulate in Knox.
> Looks like there is a least a start for this here.
> https://github.com/plaflamme/shiro-libpam4j
> libpam4j is available via Maven and uses an MIT license
> http://mvnrepository.com/artifact/org.jvnet.libpam4j/libpam4j/1.4
> This might be a great addition to Knox.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)