linux - authenticate to ldap in centos

17
2014-04
  • The Digital Ninja

    I'm trying to set centos to authenticate to a server 2003 AD. I run authconfig-gtk and select ldap for "User Information" and "Authentication" and configure it as such

    base dn: dc=test,dc=com

    ldap server: 192.168.0.1 and no TLS encryption (need to get it running first)

    on the options page

    Cache user information, use shadow passwords, password hashing algorithm md5, local authorization is sufficient for local users, create home directories on the first login

    But it wont let me ssh into the box with an AD account. Even when i log onto a local account there is a HUGE delay. 1-5 mins.

    I keep getting these errors in /var/log/secure but googling them doesn't help.

    nss_ldap: Reconnecting to LDAP server (sleeping 4 seconds)

    nss_ldap: Reconnecting to LDAP server (sleeping 8 seconds)

    I have installed SFU3.5 on the AD and filled out the unix tab for the testing users.

  • Answers
  • Andrew M.

    Before beginning, make sure you tail both /var/log/secure AND /var/log/messages; secure will give you errors from pam, but messages will give you errors from ssh (i.e., errors from querying LDAP):

    tail -f -n0 /var/log/{messages,secure}
    

    So, we have the same setup at work (Using AD server 2003). Since it sounds like you already have pam hitting LDAP (because its failing when you try to login), lets check some values in /etc/ldap.conf.

    First off, set the bind_policy from hard to soft; hard will try connecting repeatedly, exponentially increasing the sleep time between attempts (these are the errors you saw in /var/log/secure). Setting it to soft will get rid of your delays when using a local account.

    bind_policy soft
    

    Next, verify that you're using the correct settings for connecting (ssl, tls, etc.); you can use ldapsearch to test with a bit more verbosity as well. Unfortunately, without more debugging output (what server is setup, what error messages are being returned from the LDAP query, config files), I'm afraid nobody will be able to help much.

    Hope this helps you get on the right track!

    Andrew

  • lucabotti

    Check settings in ldap.conf for SFU as detailed at

    http://wiki.freaks-unidos.net/linux%20ldap%20howto#setting-up-sfu

    Mapping AD schema to posix schema makes sense to me.

  • Jason Tan

    Another approach is to have the box join the AD and authenticate using winbind.

    I'm pretty sure that authconfig will let you set up AD.

    I've never used authconfig to do AD authentication I've always set it up by hand, so you may need to run some additional commands to start winbind and join the domain:

    chkconfig winbind on service winbind start net ads join -U

    This will only do auth, if you want to do account/group info you'l need to set that up to which may involve SFU as lucabotti suggests.


  • Related Question

    LDAP authentication for SonicWALL VPN
  • colemanm

    I'm trying to configure my SonicWALL to allow LDAP authentication for VPN users. I've done this before with another device, and I remember it being pretty simple. But I can't get it to work this time for the life of me.

    When I enable "LDAP + Local Users" mode, enter the LDAP server information and AD group names, I constantly get either "LDAP authentication failed" or "Credentials not valid at LDAP server" errors. I've tried all different permutations of settings that make sense to me, with the same results. SonicWALL support is absolutely no help so far. I've followed their manual's instructions to a T, with no solution.

    Has anyone here had this same situation? I feel like I'm missing a setting somewhere...


  • Related Answers
  • Nate

    It may be small comfort, but it’s working for us. The server is Windows Server 2003 R2 and the SonicWALL has SonicOS Enhanced 4.2.0.1-12e.

    Here are the settings:

    • Authentication method for login: LDAP + Local Users
    • LDAP Server tab:
      • Chose “Give bind distinguished name”
      • Bind distinguished name: [email protected] (a user we created to allow the SonicWALL to read LDAP)
      • Use TLS (SSL) checked
        • Send LDAP ‘Start TLS’ request: checked
        • Require valid certificate from server: unchecked (we use a self-signed cert)
        • Local certificate for TLS: None
    • Did not configure RADIUS as a fallback.

    Now, before your logins will work you have to go to the Directory tab and click “Auto-configure.” If auto-configure fails, make sure the SonicWALL’s LDAP username and password (e.g. [email protected]) is correct.

    After doing auto-configure make sure “Trees containing user groups:” includes the section of your AD tree that has the users who will be logging in. Once you do that, on the “Test” tab you should be able to test with:

    • User: username (Note:AD domain name should not be included in the username because the SonicWALL will search the user contexts that were specified on the Directory tab).
    • Password: (their password)