As an administrator, I would like LDAP authenticated users to automatically have accounts created on my system so that I can automate this process.

Question

As an administrator, I would like LDAP authenticated users to automatically have accounts created on my system so that I can automate this process.

benhosmer opened this issue 8 years ago · 18 comments

Using the LDAP authenticator, I'm able to authenticate users.

For example, the user exists in the LDAP server and also has a linux user account on the hub server. Login and authentication works fine.

If a user exists in the LDAP server though but does not have a corresponding linux system account on the hub, I get the following error:

     File "/usr/lib/python3.4/site-packages/jupyterhub/spawner.py", line 439, in user_env
        home = pwd.getpwnam(self.user.name).pw_dir
    KeyError: 'getpwnam(): name not found: angie'

Can the LDAP authenticator be used with the PAM/LocalAuthenticator capabalities and create this user if they don't exist?

Answer 1 · 2016-09-01T15:35:08.000Z

It appears not, but I'm working on a PR to implement this.

Answer 2 · 2016-09-01T16:23:00.000Z

Hello!

I think the better way to do this would be to use nss_ldap + pam_ldap to make all users on ldap 'automagically' have local accounts on the machine. That's what we do at wikimedia. http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/pamnss.html is a decent guide. This has the following advantages over creating local accounts here:

Deleting accounts on LDAP deletes them from the system as well
If you are just using paswords, you can use the default PAM authenticator and it will Just Work
You can put users in different groups on LDAP and that'll be reflected here as well
It sees a ton of use among many different organizations, so a lot of your questions are probably answered!

Can you think of any advantages that putting account creation in ldapauthenticator would have, over using this setup?

Thanks!

Answer 3 · 2016-09-01T18:23:26.000Z

@yuvipanda You definitely bring up some good points, however I see a few disadvantages as well:

The system that Jupyterhub is running on now needs additional packages and configuration this opens up another attack vector and adds complexity. For some enterprise environments, it isn't very simple to add additional packages.
The possibility of conflicts with sudospawner

I modeled this implementation for ldapauthenticator after the oauthenticator.

Answer 4 · 2016-09-01T18:52:51.000Z

Can you explain what you mean by possibility of conflict with sudospawner?

Securitywise, I'd be very tempted to just say 'no' in this context -
nss_ldap and pam_ldap have seen far more audits and deployment scenarios
than ldapauthenticator+jupyterhub ever will, so any security consciousness
install should be using that setup. This is doubly important for things
like user account removals, etc. I understand the desire to not add extra
setup and fold it into this, but I think it'll be a bad addition for the
default ldapauthenticator. It'll also require that the whole jupyterhub
server run as root, which is a pretty big attack vector.

If you really want to not use pam_ldap + nss_ldap, I'd recommend creating a
subclass of ldapauthenticator that does that as a separate project, but not
as part of ldapauthenticator itself.

On Thu, Sep 1, 2016 at 11:23 AM, Ben Hosmer notifications@github.com
wrote:

@yuvipanda https://github.com/yuvipanda You definitely bring up some
good points, however I see a few disadvantages as well:

The system that Jupyterhub is running on now needs additional
packages and configuration this opens up another attack vector and adds
complexity. For some enterprise environments, it isn't very simple to add
additional packages.

The possibility of conflicts with sudospawner

I modeled this implementation for ldapauthenticator after the
oauthenticator
https://github.com/jupyterhub/oauthenticator/tree/master/oauthenticator.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23sautOvBBlnLzT9iaSI2_G6fWUmdks5qlxgegaJpZM4Jx4M_
.

Yuvi Panda T
http://yuvi.in/blog

Answer 5 · 2016-09-01T18:53:34.000Z

I can also write up a doc on how to setup pam_ldap + nss_ldap along with
jupyterhub, if that would make this problem easier.

On Thu, Sep 1, 2016 at 11:52 AM, Yuvi Panda yuvipanda@gmail.com wrote:

Can you explain what you mean by possibility of conflict with sudospawner?

Securitywise, I'd be very tempted to just say 'no' in this context -
nss_ldap and pam_ldap have seen far more audits and deployment scenarios
than ldapauthenticator+jupyterhub ever will, so any security consciousness
install should be using that setup. This is doubly important for things
like user account removals, etc. I understand the desire to not add extra
setup and fold it into this, but I think it'll be a bad addition for the
default ldapauthenticator. It'll also require that the whole jupyterhub
server run as root, which is a pretty big attack vector.

If you really want to not use pam_ldap + nss_ldap, I'd recommend creating
a subclass of ldapauthenticator that does that as a separate project, but
not as part of ldapauthenticator itself.

On Thu, Sep 1, 2016 at 11:23 AM, Ben Hosmer notifications@github.com
wrote:

@yuvipanda https://github.com/yuvipanda You definitely bring up some
good points, however I see a few disadvantages as well:

The system that Jupyterhub is running on now needs additional
packages and configuration this opens up another attack vector and adds
complexity. For some enterprise environments, it isn't very simple to add
additional packages.

The possibility of conflicts with sudospawner

I modeled this implementation for ldapauthenticator after the
oauthenticator
https://github.com/jupyterhub/oauthenticator/tree/master/oauthenticator
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23sautOvBBlnLzT9iaSI2_G6fWUmdks5qlxgegaJpZM4Jx4M_
.

Yuvi Panda T
http://yuvi.in/blog

Yuvi Panda T
http://yuvi.in/blog

Answer 6 · 2016-09-01T19:43:02.000Z

It's not a matter of not knowing how to implement PAM, LDAP, and NSS, it's more of the added complexity.

Yeah, I certainly agree they're probably more secure than this smaller project will be.

ldapauthenticator could still be used even for a non-root user though if the user that is running hub has sudo privileges to useradd?

Answer 7 · 2016-09-01T19:58:18.000Z

@yuvipanda before I go a create a separate module, I want to make sure this PR isn't going anywhere.

What about the oauthenticator? Even for the sake of uniformity across jupyterhub?

Answer 8 · 2016-09-01T23:45:50.000Z

I think it might make more sense in OAuthenticator, since there's no
equivalent of nss_ldap for use there. I don't think we should have that
functionality in the core ldapauthenticator module. I will work on a doc
for using nss_ldap though. I'll also be happy to CR the separate module if
you want me to.

To recap,

This functionality is already provided by the battle tested pam_ldap +
nss_ldap modules
Doing this 'right' is pretty complex, since you need to figure out how
to handle deletions, changes in username / attributes, etc. pamd_ldap +
nss_ldap deal with all of this for us.
While setting up pam_ldap + nss_ldap requires root or sudo privs, so
does useradd.
This is a very common use case, so I'll add documentation making this
clearer.
OAuthenticator does include this functionality, which I think is ok
because there's no equivalent of nss_ldap for oauth. I also note that not
all of them provide this - the Mediawiki one, for example. It would be
fairly complex in that case, since MediaWiki usernames can contain
characters that are not permitted in unix accounts.

Thank you for talking it through, and I hope I have been able to
communicate my reasons clearly. Looking forward to helping out the new
module in any way I can :)

On Thu, Sep 1, 2016 at 12:58 PM, Ben Hosmer notifications@github.com
wrote:

@yuvipanda https://github.com/yuvipanda before I go a create a separate
module, I want to make sure this PR isn't going anywhere.

What about the oauthenticator? Even for the sake of uniformity across
jupyterhub?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23pme2mzFRgipd6Mh9qclBQf_P6rqks5qly5agaJpZM4Jx4M_
.

Yuvi Panda T
http://yuvi.in/blog

Answer 9 · 2016-09-02T00:14:17.000Z

Your reasoning is sound. Thanks for the engagement on this. I'll likely create a small module that extends the ldapauthenticator initially.

Answer 10 · 2016-09-02T02:34:43.000Z

yw! I wonder if you can just do this in your jupyterhub_config file itself.
The Oauthenticator ones just seem to be including a mixin and nothing
else...

On Thu, Sep 1, 2016 at 5:14 PM, Ben Hosmer notifications@github.com wrote:

Your reasoning is sound. Thanks for the engagement on this. I'll likely
create a small module that extends the ldapauthenticator initially.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23qfNUf5ad0r81yn-g-GtR5dxFTbeks5ql2pZgaJpZM4Jx4M_
.

Yuvi Panda T
http://yuvi.in/blog

Answer 11 · 2016-09-02T15:19:24.000Z

I'm curious, what would this look like in the config file?

Answer 12 · 2016-09-19T09:36:54.000Z

@benhosmer, @yuvipanda please share the config file

Answer 13 · 2016-09-19T10:01:12.000Z

I never got it to work in the config file. I imagine you could just do something similar to this:

from jupyterhub.auth import Authenticator, LocalAuthenticator
from ldapauthenticator import LDAPAuthenticator

class LocalLDAPCreateUsers(LocalAuthenticator, LDAPAuthenticator):

    """Create local user accounts based on LDAP authentication"""
    pass

c.JupyterHub.authenticator_class = 'ldapcreateusers.LocalLDAPCreateUsers'
c.LocalLDAPCreateUsers.server_address = 'some.ldap.server'
c.LocalLDAPCreateUsers.server_port = 389
c.LocalLDAPCreateUsers.use_ssl = False
c.LocalLDAPCreateUsers.bind_dn_template = 'uid={username},dc=yourdomain,dc=com'
c.LocalLDAPCreateUsers.create_system_users = True

Or just $ pip install jupyterhub-ldapcreateusers: https://github.com/benhosmer/jupyterhub-ldapcreateusers

Answer 14 · 2017-06-14T22:46:59.000Z

@venkatchetkuri You may wish to look at https://github.com/bloomberg/jupyterhub-kdcauthenticator to see if it would fulfill your requirements.

Answer 15 · 2017-06-27T04:18:30.000Z

@willingc Here is my use case:
Run spark jobs in JupyterHub notebooks against a Kerborised (YARN/Spark) cluster.
I don't want LDAP users to have Kerberos principals.
I am allowed to create service principals.

What i did so far on a single machine is :

Installed Jupyterhub - Success.
https://github.com/jupyterhub/jupyterhub
Installed LIvy - Success.
https://github.com/cloudera/livy
Added this node as a gateway node to the Cloudera cluster - Success.
configured LDAP authenticator -Success.
https://github.com/jupyterhub/ldapauthenticator
Sparkmagic - cannot start the pyspark and spark kernals for LDAP users.
https://github.com/jupyter-incubator/sparkmagic
Kerberos Authentication - installed requests-kerberos package and KDC authenticator.
https://github.com/bloomberg/jupyterhub-kdcauthenticator

Error message when I'm trying to run :
#KRB5_CONFIG=/etc/krb5.conf
#KRB5_KTNAME=/opt/livy/jhub.keytab
#jupyterhub --ip=public.ip --port=8000 --no-ssl --config=/opt/jupyterhub_config.py

[C 2017-06-27 21:10:31.135 JupyterHub application:90] Bad config encountered during initialization:
[C 2017-06-27 21:10:31.135 JupyterHub application:91] The 'authenticator_class' trait of <jupyterhub.app.JupyterHub object at 0x7f03e8070c88> instance must be a type, but 'kdcauthenticator.kdcauthenticator.KDCAuthenticator' could not be imported

Being a newbie to Jupyter/Spark and Kerberos, I'm not able figure out what I'm missing.

Here I am attaching the overall architecture and the configuration files of livy and jupyterhub.

jupyterhub_config.txt
livy_conf.txt

Answer 16 · 2018-10-16T14:34:27.000Z

I can also write up a doc on how to setup pam_ldap + nss_ldap along with
jupyterhub, if that would make this problem easier.

Hi, I hope this isn't an off-topic, but I would really appreciate such a guide, or a push in the right direction, and this issue seems to be exactly about the problem I am experiencing. I've managed to get nslcd to work, and I am even able to log in to JupyterHub via PAM+LDAP, but as soon as I'm in, I get the following error:

[I 2018-10-16 14:29:39.676 JupyterHub spawner:1100] Spawning jupyterhub-singleuser --port=53828
[E 2018-10-16 14:29:39.791 JupyterHub user:477] Unhandled error starting olbl's server: Exception occurred in preexec_fn.
[E 2018-10-16 14:29:39.874 JupyterHub web:1670] Uncaught exception GET /hub/user/olbl/ (10.84.55.155)
    HTTPServerRequest(protocol='https', host='jupyter.internal.bluetest.se', method='GET', uri='/hub/user/olbl/', version='HTTP/1.1', remote_ip='10.xxx.xxx.xxx')

I had the same issue even when I had used the LDAP-plugin for JupyterHub, but since the user in question is in the right group, that has access to the Anaconda folder, I am assuming this has to do with PAM-configuration? There I am truly lost, so any suggestions would be welcome. Almost all users simply get an error that their home folder does not exist...

Thanks in advance!

Answer 17 · 2019-06-04T11:21:23.000Z

Can you explain what you mean by possibility of conflict with sudospawner?

Securitywise, I'd be very tempted to just say 'no' in this context -
nss_ldap and pam_ldap have seen far more audits and deployment scenarios
than ldapauthenticator+jupyterhub ever will, so any security consciousness
install should be using that setup. This is doubly important for things
like user account removals, etc. I understand the desire to not add extra
setup and fold it into this, but I think it'll be a bad addition for the
default ldapauthenticator. It'll also require that the whole jupyterhub
server run as root, which is a pretty big attack vector.

If you really want to not use pam_ldap + nss_ldap, I'd recommend creating a
subclass of ldapauthenticator that does that as a separate project, but not
as part of ldapauthenticator itself.

On Thu, Sep 1, 2016 at 11:23 AM, Ben Hosmer notifications@github.com
wrote:

@yuvipanda https://github.com/yuvipanda You definitely bring up some
good points, however I see a few disadvantages as well:

The system that Jupyterhub is running on now needs additional
packages and configuration this opens up another attack vector and adds
complexity. For some enterprise environments, it isn't very simple to add
additional packages.

The possibility of conflicts with sudospawner

I modeled this implementation for ldapauthenticator after the
oauthenticator
https://github.com/jupyterhub/oauthenticator/tree/master/oauthenticator.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23sautOvBBlnLzT9iaSI2_G6fWUmdks5qlxgegaJpZM4Jx4M_
.

Yuvi Panda T
http://yuvi.in/blog

@yuvipanda does this apply to windows platform as well?

Answer 18 · 2023-06-06T13:59:14.000Z

There is an alternative ldap authenticator with user home creation support, but a little bit outdated:
https://github.com/hansohn/jupyterhub-ldap-authenticator