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]

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?

[benhosmer]

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

[yuvipanda]

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:

1. Deleting accounts on LDAP deletes them from the system as well
2. If you are just using paswords, you can use the default PAM authenticator and it will Just Work
3. You can put users in different groups on LDAP and that'll be reflected here as well
4. 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!

[benhosmer]

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

1. 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.
2. The possibility of conflicts with sudospawner

I modeled this implementation for ldapauthenticator after the oauthenticator.

[yuvipanda]

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:

1. 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.
2. 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 https://github.com/jupyterhub/ldapauthenticator/issues/19#issuecomment-244167372, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB23sautOvBBlnLzT9iaSI2_G6fWUmdks5qlxgegaJpZM4Jx4M_ .

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

[yuvipanda]

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:

1. 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.
2. 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 https://github.com/jupyterhub/ldapauthenticator/issues/19#issuecomment-244167372, 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

[benhosmer]

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?

[benhosmer]

@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?

[yuvipanda]

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,

1. This functionality is already provided by the battle tested pam_ldap + nss_ldap modules
2. 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.
3. While setting up pam_ldap + nss_ldap requires root or sudo privs, so does useradd.
4. This is a very common use case, so I'll add documentation making this clearer.
5. 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 https://github.com/jupyterhub/ldapauthenticator/issues/19#issuecomment-244193922, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB23pme2mzFRgipd6Mh9qclBQf_P6rqks5qly5agaJpZM4Jx4M_ .

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

[benhosmer]

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

[yuvipanda]

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 https://github.com/jupyterhub/ldapauthenticator/issues/19#issuecomment-244249630, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB23qfNUf5ad0r81yn-g-GtR5dxFTbeks5ql2pZgaJpZM4Jx4M_ .

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

[benhosmer]

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

[tredence123]

@benhosmer, @yuvipanda please share the config file

[benhosmer]

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

[willingc]

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

[venkatchetkuri]

@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 :

1. Installed Jupyterhub - Success. https://github.com/jupyterhub/jupyterhub

2. Installed LIvy - Success. https://github.com/cloudera/livy

3. Added this node as a gateway node to the Cloudera cluster - Success.

4. configured LDAP authenticator -Success. https://github.com/jupyterhub/ldapauthenticator

5. Sparkmagic - cannot start the pyspark and spark kernals for LDAP users. https://github.com/jupyter-incubator/sparkmagic

6. 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

[olegbliaher]

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!

[epignatelli]

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:

1. 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.
2. 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?

[blodone]

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