Forums

Resolved
0 votes
There were some issues with openLDAP when 6.6 came out, I haven't updated a few of my clients servers to that as such due to this. I just wanted to know if this has been resolved now and is it back to being stable so I can safely update servers to 6.6 now?
Tuesday, April 21 2015, 09:25 AM
Share this post:
Responses (8)
  • Accepted Answer

    Hans
    Hans
    Offline
    Wednesday, September 16 2015, 08:14 PM - #Permalink
    Resolved
    0 votes
    I tried and tried.. still no luck :(
    I changed the /etc/init.d/slapd file so ldap uses non-secure ldap access, as per previous post.

    I have a vanilla Mac OS X Yosemite. I am trying to add the ClearOS server as a Network Account Server.
    A picture says more than a thousand words; I recorded a video.

    This is what I do:
    - First connect to my old ClearOS 5.2 machine called "poseidon",
    - After that I am trying to connect to my ClearOS 6 machine, "hera"

    See the difference?



    P.S. If I clicked "Continue" with the first attempt (poseidon) it would result in a green dot (i.e. successfully recognized).
    If you are reading this in a Google Chrome browser, be sure to accept the unsafe source.. :p The source is YouTube owned by... Google. Nice.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, September 12 2015, 08:11 AM - #Permalink
    Resolved
    0 votes
    @Hans,
    I think your solution is here. You may even be able to change the lines to
    harg="$harg ldaps://$LANIP/ ldap://$LANIP/"
    to allow both ldap and ldaps access.
    The reply is currently minimized Show
  • Accepted Answer

    Hans
    Hans
    Offline
    Friday, September 11 2015, 11:41 AM - #Permalink
    Resolved
    0 votes
    I just noticed your reply. I will try when possible.

    Let's say this won't fix my issues with OpenLDAP + ClearOS 6 + MacOSX (pessimist as I am)...

    Is it possible to hack/change COS6 OpenLDAP settings this way it behaves like OpenLDAP COS 5.2? Without SSL/TLS authentication? I remember a post where a some LAN/Network settings needed to change in order to let make local network behave differently. Did that already, didn't change a thing.

    I still have a old ClearOS 5.2 machine running for ldap authentication MacOSX clients solely. I want to remove that machine and replace it with COS 6.

    I guess I'm very close in making this work. Why?

    In MacOSX Snow Leopard/Yosemite client's terminal I can su <ldapuser> without problems.
    When asked for <id> I get the correct userid details (uid number and gid (allusers), etc.)

    Does this mean that SSL is working?

    Network login is enabled on the MacOSX "Users & Groups" > "Login Options" settings page. See option below:
    http://community.centrify.com/t5/image/serverpage/image-id/812i23698BB255670222/image-size/original?v=mpbl-1&px=-1
    I see a list of all COS LDAP users in the list when I click this button.

    So far so good.

    The problem is that Apple's Directory Utility just won't let me find/connect to COS 6 Ldap. It does find my COS 5.2 right away, within Yosemite, it warns for the non-SSL connection. When added manually it just isn't able to find the machine. I have no firewalls enabled, both COS and MacOSX. I just can't logon as a ldap user on MacOSX.

    Some logging:
    ip COS6: 192.168.1.50
    ip MacOSX client: 192.168.1.91
    # cat /var/log/ldap | grep macosx
    Sep 8 16:23:57 hera slapd[1567]: conn=1605 op=36 SRCH base="ou=macosxodconfig,cn=config,ou=macosx,dc=home,dc=lan" scope=0 deref=0 filter="(objectClass=*)"
    Sep 8 16:23:57 hera slapd[1567]: => access_allowed: search access to "ou=macosxodconfig,cn=config,ou=macosx,dc=home,dc=lan" "entry" requested
    Sep 8 16:23:57 hera slapd[1567]: => access_allowed: search access to "ou=macosxodconfig,cn=config,ou=macosx,dc=home,dc=lan" "objectClass" requested
    Sep 8 16:23:57 hera slapd[1567]: => access_allowed: read access to "ou=macosxodconfig,cn=config,ou=macosx,dc=home,dc=lan" "entry" requested
    Sep 8 16:23:57 hera slapd[1567]: => access_allowed: read access to "ou=macosxodconfig,cn=config,ou=macosx,dc=home,dc=lan" "ou" requested
    Sep 8 16:23:57 hera slapd[1567]: => access_allowed: read access to "ou=macosxodconfig,cn=config,ou=macosx,dc=home,dc=lan" "objectClass" requested
    Sep 8 16:23:57 hera slapd[1567]: => access_allowed: read access to "ou=macosxodconfig,cn=config,ou=macosx,dc=home,dc=lan" "description" requested

    I get a lot of accepted connections:
    # cat /var/log/ldap | grep 192.168.1.91
    Sep 10 21:36:41 hera slapd[1567]: conn=3570 fd=11 ACCEPT from IP=192.168.1.91:52849 (IP=192.168.1.50:636)


    Update:
    Just when I was collecting log information to this topic I noticed the following:
    # cat /var/log/messages | grep 192.168.1.91
    Sep 10 19:38:55 hera rpc.mountd[14641]: refused mount request from 192.168.1.91 for / (/): not exported
    Sep 10 19:38:55 hera rpc.mountd[14641]: refused mount request from 192.168.1.91 for / (/): not exported
    Sep 10 19:39:06 hera rpc.mountd[14641]: refused mount request from 192.168.1.91 for / (/): not exported
    Sep 10 19:39:06 hera rpc.mountd[14641]: refused mount request from 192.168.1.91 for / (/): not exported

    The issue is related to the Mac not being able to mount the / directory of the server.
    Why would it want to do that? I guess it needs to mount the <ldapuser> home directory to /home. What option/setting has control over this?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 22 2015, 11:55 AM - #Permalink
    Resolved
    0 votes
    Hans wrote:

    @James, any luck getting a decent ldap setup yet? I have problems getting mac os x clients to authenticate to ClearOS 6.6 Openldap.
    Connecting from the specific clients with ldap editors like LDAP Admin work fine. I think I'm still missing some configuration steps on the Mac to finish authentication. It just won't let me find the ldap server. It says, "Server not responding".


    Hans I recently just had an issue with Ldap on a clients machine, it wouldn't load up at all, doing what was done in the previous ldap thread resolved nothing for me. I was able to fix it by nuking the accesslogs in /var/lib/ldap/accesslogs/ please back yours up before you do this by copying the ldap folder


    cp -r /var/lib/ldap/ /usr/src/ldapbk
    chown ldap.ldap /var/lib/ldap/ -R
    /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
    rm -rf /var/lib/ldap/accesslog/*
    service slapd restart
    service nslcd restart
    service nscd restart


    I hope this works for you. It definitely did for me.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 16 2015, 02:49 PM - #Permalink
    Resolved
    0 votes
    @Hans Ldap works now with doing the yum update, for me personally. I'd disable local network if your still having problems but it should be fine.
    The reply is currently minimized Show
  • Accepted Answer

    Hans
    Hans
    Offline
    Tuesday, July 14 2015, 02:17 PM - #Permalink
    Resolved
    0 votes
    @James, any luck getting a decent ldap setup yet? I have problems getting mac os x clients to authenticate to ClearOS 6.6 Openldap.
    Connecting from the specific clients with ldap editors like LDAP Admin work fine. I think I'm still missing some configuration steps on the Mac to finish authentication. It just won't let me find the ldap server. It says, "Server not responding".
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 21 2015, 02:50 PM - #Permalink
    Resolved
    0 votes
    Great news Dave, the ldap not working was quite an issue for me on one clients server I was able to resolve it eventually by not publishing ldap at all and then stopped all other clearos servers from updating to 6.6 because of it. Hearing this relieves me and I'll make sure I enable updates for 6.6 now then. Thanks for the update.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 21 2015, 02:12 PM - #Permalink
    Resolved
    0 votes
    ClearOS 6.6 has been replaced with ClearOS 6.6.1. The OpenLDAP fix that I'm thinking about should be fixed there. This would be the issue where error text gets passed to the app-network API module.
    The reply is currently minimized Show
Your Reply