Using Centrify for AD authentication

Hi, we are trying to authenticate using Centrify AD. Here is a summary of our configurations:

  1. AuthType Basic with htpasswd authentication - working
    -Able to logon successfully and access the OOD dashboard.

  2. AuthType CENTRIFYDC with AD authentication - not working
    -we are using Centrify for AD authentication. We know that we are authenticating correctly with AD through Centrify. Once authenticated, we get the following error from the ood dashboard. The only difference between this case and the case above is changing the /etc/ood/config/ood_portal.yml file to use AD authentication with Centrify.

Do you have any advice on what we can try next or how to turn on additional debugging messages?
We also have the apache error log file, but don’t see an option to add an attachment here.

I think there’s a bug around handling changes. If you remove that file, /var/run/ondemand-nginx/tonas/passenger.sock then re-authenticate, it should work.

Or is it the case that, even after removing this file, you always get this error?

Hi Jeff, we tried removing the file, but still get the same errors.

OK so the nginx if failing to start, or already did. Is the ‘basic’ auth user is just a regular local user on that system, not an AD user? Is that right? If so, I’d guess this is the crux of our issue. That nginx is having a hard time switching to the AD user.

Can you find output like this. What the socket file looks like in terms of permissions and what process still has an open file handle to it (if any).

[jeff@993552b7f5c8 /]$ sudo ls -rtl /var/run/ondemand-nginx/jeff/passenger.sock
srw-rw-rw-. 1 root root 0 Sep  4 14:26 /var/run/ondemand-nginx/jeff/passenger.sock
[jeff@993552b7f5c8 /]$ lsof | grep passenger.sock
nginx     347                 jeff    6u     unix 0x00000000df115af5      0t0  7973151 /var/run/ondemand-nginx/jeff/passenger.sock type=STREAM
[jeff@993552b7f5c8 /]$ ps -lf 347
F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY        TIME CMD
5 S jeff       347   345  0  80   0 - 26701 -      14:26 ?          0:00 nginx: worker process

You may see something here /var/log/ondemand-nginx/tonas/error.log from the initial nginx crashing.

We can turn up logging by editing /opt/ood/nginx_stage/templates/pun.conf.erb (please back this up and revert once we’re done!) but I’m not sure if anything will show up.

# from
error_log   <%= error_log_path %>;
# to
error_log   <%= error_log_path %> debug;

Hi Jeff, we are using basic authentication with a local user on the system (which happens to have the same uid as the AD user). Please see the outputs below:

[root@ohylood1-d config]# ls -ltr /var/run/ondemand-nginx/tonas/passenger.sock
srw-rw-rw-. 1 root root 0 Sep 4 12:44 /var/run/ondemand-nginx/tonas/passenger.sock

[root@ohylood1-d config]# lsof | grep passenger.sock
nginx 57728 root 6u unix 0xffff92fc7c301000 0t0 1146779 /var/run/ondemand-nginx/tonas/passenger.sock
nginx 57731 tonas 6u unix 0xffff92fc7c301000 0t0 1146779 /var/run/ondemand-nginx/tonas/passenger.sock

[root@ohylood1-d tonas]# ps -lf 57728
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
5 S root 57728 1 0 80 0 - 25041 sigsus 12:44 ? 0:00 nginx: master process (tonas) -c /var/
[root@ohylood1-d tonas]# ps -lf 57731
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
5 S tonas 57731 57728 0 80 0 - 25563 ep_pol 12:44 ? 0:00 nginx: worker process

tail of the /var/log/ondemand-nginx/tonas/error.log file

I’m not sure if the overlapping UID is throwing this off, but I’d like to rule it out. Can you try with a different user or change the UID of the local user to something that doesn’t overlap with another.

Hi Jeff, could you elaborate on what you mean by overlapping UIDs? We tried authenticating with another user, and it gives the same nginx bind error (authentication with Centrify). We can only authenticate using basic authentication. Thanks

This is what I’d meant. You’d said the local and AD users have the same uid. Is this the case with the other user as well? This is what I’d like to rule out.

Hey where u ever able to integrate Centrify with Apache? I feel like where we left it there was some discrepancy between AD users and local users?