How to make a user an admin in Hue


If you followed my previous post on how to configure Hue to use PAM for authentication, I mentioned that if you have previously logged into Hue before making this change then you will no longer be able to login with the admin account you originally created.

There is an easy way around this if you are using the default database. First you’ll need to SSH to the server where Hue is installed, then start the Hue shell.

sudo /usr/share/hue/build/env/bin/hue shell

Then run the following Python code to make a user the administrator:

from django.contrib.auth.models import User

a = User.objects.get(username='<username>')

a.is_staff = True

a.is_superuser = True

Obviously replacing <username> with the actual user. I found this solution in the Cloudera community forums.

Configuring Hue on HDInsight to use PAM Authentication


In a previous post I covered a fix to a Microsoft provided custom script action to support installing Hue on HDInsight 3.5 clusters – I am happy to report that Microsoft have since updated the script. However, the script defaults to using the django backend for user authentication – which isn’t terribly useful, unless you want to have to maintain a separate set of accounts to your operating system. In a future post I will cover configuring Hue to use LDAP authentication but here I will be discussing PAM.

User Accounts

First off if you wish to use PAM to authenticate users, you will need to ensure you have created user accounts across the nodes in the cluster. This is where you’re better off using LDAP – or at least you would be if domain joined clusters were not in preview and currently only supported with “Hadoop” cluster types. That’s another point, Microsoft provides a number of different types of clusters but for some reason decided to label the one that only provides Hive, a Hadoop cluster.

Configuring Hue

Next you will need to edit the hue.ini configuration file under /usr/share/hue/desktop/conf/hue.ini

Under the [[auth]] section add the following line:


This enables PAM authentication. In case you’ve used Hue before and are wondering the script action installs Hue 3.8.1, which only supports one authentication backend – so we can’t configure more. Note that if you’ve already logged into the Hue web interface and created you’re admin account – you will no longer be able to use it after this (there is a way to make a new user the admin via the command line which I will cover in another post).

Next you need to tell Hue which service to use when querying PAM:

pam_service=sudo sshd login

Here we configure multiple options

Following this you will have to restart Hue:

systemctl restart hue

PAM Error

The only problem is you still will be unable to login with an operating system user. After attempting to login if you run:

systemctl status hue

You will see an error message similar to the following:

pam_winbind(login:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user

I was confused by this and couldn’t figure out what the problem was until I came across this post on stackexchange:

Which indicated that this is because Hue runs as a normal user that does not have permission to access authentication data.

So how do we fix this? Well sadly I haven’t found a more secure way but to get around this you will need to run Hue as root by modify the systemd init file /etc/systemd/system/

Change User=hue to root.

Obviously it is less than ideal to run a web application as root as it means a vulnerability in the web application can be used to compromise the entire system. This is why you’re better off using LDAP.

ADFS WAP behind Azure Application Gateway

Microsoft Azure

Some time ago i wrote up a post (located here) explaining how you can setup traffic manager with ADFS and have proper monitoring of the service. Today i will go over how to setup ADFS behind the Azure Application Gateway. This will enable you to protect your ADFS service and monitor it with the WAF provided by the application gateway.

Before we begin one prerequisite which i am still not sure if its really needed but i had problems and i believe this fixed it:

You need to set the default HTTPS Binding, i believe this is required as i am not sure if the health probe is truly SNI compliant, i might be wrong here but it doesn’t hurt to set this. To set it you simply need to run the following command on the WAP servers (just change the cert hash):

Ones that’s done create a Application gateway in Azure and do the following:

  1. Create a Frontend listener with thew following settings:
    • HTTPS Protocol
    • Listen on port 443
    • Multi-Site type, you can do basic but that will limit your application gateway to only the ADFS service for port 443
    • Provide a PFX file of your ADFS certificate. make sure you include the private key and a strong password
  2. Create a Health Probe with thew following settings (just change the host):
    • The path (so you can copy and paste): /adfs/ls/IdpInitiatedSignOn.aspx
  3. Create a HTTP Setting with thew following settings
    • HTTPS Protocol
    • Cookie based affinity: Disabled (you really don’t need that for ADFS)
    • Port 443
    • Export your ADFS certificate as a base 64 format (do not include the private key) and add it.
    • Tick the “Custom probe” and select the probe we created earlier
  4. Create a Backendpool which includes all your WAP servers
  5. Crete a Basic Rule using the objects created earlier.

And that’s it, this is not only a secure solution but it will give you a proper monitoring of both the WAP and ADFS servers. Works great with loadbalancing between on-prem and Azure.