[
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 5:00 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. (this is for security reasons since it is a vulnerability).
Then if using LPDAP PAM authentication you will need to first set Linux
authentication using PAM/LDAP. Check "Linux Server Hacks volume two (Willian
von Hagen - o'reilly's book"
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 setup.
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>
Finally, 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 LDAP nuances. 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 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.
> 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)
