kvspb / nginx-auth-ldap

LDAP authentication module for nginx
BSD 2-Clause "Simplified" License
731 stars 251 forks source link

LDAP cache not clearing out #141

Closed al-jeyapal closed 6 years ago

al-jeyapal commented 8 years ago

Summary:

I have the module configured to allow access to a URL if the user is in a specific LDAP group. I can successfully login with that user and be granted access to the URL page. However, if I remove the user from the LDAP group, I can still login and access the URL.

Configuration:

http {                                                                              
    auth_ldap_cache_enabled on;                                                     
    auth_ldap_cache_expiration_time 100;                                            
    auth_ldap_cache_size 1000;                                                      

    ldap_server LDAP1 {                                                             
        url "ldaps://ldap:3269/DC=test,DC=,DC=com?sAMAccountName?sub?";
        binddn "test\\user1";                                                        
        binddn_passwd "password";                                                 
        connect_timeout 5s;                                                         
        bind_timeout 5s;                                                            
        request_timeout 5s;                                                         
        satisfy any;                                                                
        require group 'CN=group1,CN=Users,DC=test,DC=com';
        group_attribute_is_dn on;                                                   
        group_attribute member;                                                     
    }                                             
    server {                                                                     
        access_log log/nginx/service_access.log;                                                                 
        listen 80;                                                         
        server_name service.test.com;                        
        location / {                                                             
            proxy_pass http://service:3000;                                      
        }                                                                        
        auth_ldap "Enter AD credentials:";                                       
        auth_ldap_servers LDAP1;                                                 
    }               
}

Steps to :

It appears that the module is not expiring entries in the cache properly. If I send nginx a SIGHUP, then the user is denied access as expected (but continues to be denied access if I re-add them to the LDAP group, unless I do another SIGHUP) If I disable caching via: auth_ldap_cache_enabled off; then the problem goes away.

nicolaszordan commented 6 years ago

I had the same problem and thought that the cache wasn't clearing when the expiration_time was reached. But it turned out to be me who misunderstood that the auth_ldap_cache_expiration_time was in seconds and not milliseconds by default.

landryb commented 6 years ago

Fwiw, i second the OP - i experienced the same with caching (and afaict from reading the code, the cache expiration time is in milliseconds..cf https://github.com/kvspb/nginx-auth-ldap/blob/master/ngx_http_auth_ldap_module.c#L940 - seems it defaults to 10s/1000ms), and so far the only option i had found was to restart nginx to get a clean cache. Next time i'm removing some users from a group i'll try the SIGHUP way but that shouldnt be needed. Maybe something changed in nginx itself wrt cache expiration and this module wasnt updated ?

landryb commented 6 years ago

Dammit, seems @nicolaszordan is right and i'm wrong. When i look at my ldap server logs, it effectively seems that the cache expiration is in seconds... this doesnt make sense/match the code layout. crazy ?

al-jeyapal commented 6 years ago

We no longer use this solution for our LDAP authentication so are not in a position to re-test. Based on the above comments it appears that the bug is a misunderstanding on our part (i.e. the timeout is in seconds not milliseconds). As such we are closing this ticket.