Community Forum

Resolved
0 votes
I have searched the forum, and i have tried suggested changes, but it is not working for me

running ClearOS 6.8.0.

My "publish policy" is set to "local network"
My "account access" is set to "anonymous"

These are the same settings i had on 5.2, and it worked fine

I am trying to update my "Jenkins" ldap link, and i am getting "connection refused". I am using local IP as my ldap link (ldap://192.168.xxx.xxx:389). I have tried both ldap and ldaps.

Yes, i do have bind DN and bind Password copy/pasted into jenkins.

what else am i missing? what else do i need to enable to get LDAP going?
Saturday, February 11 2017, 12:48 AM
Share this post:
Responses (9)
  • Accepted Answer

    Friday, October 27 2017, 07:41 AM - #Permalink
    Resolved
    0 votes
    Thank you Nick for your attention,
    Network setting are correct:
    [root@intranet ~]# netstat -peanut | grep slapd
    tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 0 21346479 10870/slapd
    tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 0 21346476 10870/slapd
    tcp 0 0 127.0.0.1:389 127.0.0.1:50282 ESTABLISHED 55 23363070 10870/slapd
    tcp 0 0 127.0.0.1:389 127.0.0.1:50274 ESTABLISHED 55 23358790 10870/slapd
    tcp 0 0 127.0.0.1:389 127.0.0.1:50284 ESTABLISHED 55 23363072 10870/slapd
    tcp 0 0 127.0.0.1:389 127.0.0.1:50278 ESTABLISHED 55 23360315 10870/slapd
    tcp 0 0 127.0.0.1:389 127.0.0.1:50280 ESTABLISHED 55 23363068 10870/slapd
    tcp6 0 0 :::636 :::* LISTEN 0 21346480 10870/slapd


    but you inspired me to made another tests. Conlusion is ClearOS works perfect:-)
    I try connect to ClearOS LDAPs from another one Wordpress instance from different hosting provider and from LdapAdmin. Wordpress LDAP still doesn't work but LdapAdmin connect without problem.

    Thanks again Nick,

    Przemo
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 25 2017, 04:17 PM - #Permalink
    Resolved
    0 votes
    I've tried investigating a bit. As far as I can see, if Publish Policy is set to All networks LDAP listens as follows:
    [root@gateway-h ~]# netstat -peanut | grep slapd
    tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 0 50041 7936/slapd
    tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 0 50038 7936/slapd
    tcp6 0 0 :::636 :::* LISTEN 0 50042 7936/slapd
    It should, therefore, respond to all LDAPS requests from anywhere.

    If Publish Policy is set to Local Network, it listens to LDAPS on its LAN IP::
    [root@gateway-h ~]# netstat -peanut | grep slapd
    tcp 0 0 172.17.2.121:636 0.0.0.0:* LISTEN 0 51962 8128/slapd
    tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 0 51960 8128/slapd
    This is the WAN interface listening, but in Standalone - no firewall mode the normal interface is designated as a WAN interface.

    Since you are using LDAPS, I would have expected either Publish Policy to work in your scenario. Perhaps the problem is elsewhere (the Wordpress connector?).

    What is the output to "netstat -peanut | grep slapd"?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 25 2017, 10:43 AM - #Permalink
    Resolved
    0 votes
    I've similar problem but with connection from external network (behind firewall - Fortigate).

    ClearOS 7.4.0 as "Standalone - no firewall" (one NIC as external).
    Own wildcard certificate used by slapd too
    "publish policy" is set to "external network"
    "account access" is set to "anonymous".

    I would like to use LDAP authentication for Wordpress by plugin "Active Directory Integration / LDAP Integration". Everything works great with Wordpress installation in local network, but doesn't work from outside. Firewall is set correctly: similar rule as for ssh that works, Fortigate report - "Action Accept: session close", Received Bytes 6 kB, Received Packets 9, Sent Bytes 574 B, Sent Packets 8.
    Log when connection is initiated (unsuccesful) from external network:
    12:04:46.708270 IP (tos 0x0, ttl 51, id 60999, offset 0, flags [DF], proto TCP (6), length 52)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [S], cksum 0x4010 (correct), seq 2171832615, win 29200, options [mss 1440,nop,nop,sackOK,nop,wscale 10], length 0
    12:04:46.708313 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    intranet.arpol.pl.ldaps > gateway.26252: Flags [S.], cksum 0x4985 (incorrect -> 0x212c), seq 2802350009, ack 2171832616, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    12:04:46.738839 IP (tos 0x0, ttl 51, id 61000, offset 0, flags [DF], proto TCP (6), length 40)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [.], cksum 0xd3f1 (correct), seq 1, ack 1, win 29, length 0
    12:04:46.742571 IP (tos 0x0, ttl 51, id 61001, offset 0, flags [DF], proto TCP (6), length 205)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x660e (correct), seq 1:166, ack 1, win 29, length 165
    12:04:46.742609 IP (tos 0x0, ttl 64, id 59204, offset 0, flags [DF], proto TCP (6), length 40)
    intranet.arpol.pl.ldaps > gateway.26252: Flags [.], cksum 0x4979 (incorrect -> 0xd27c), seq 1, ack 166, win 237, length 0
    12:04:46.744778 IP (tos 0x0, ttl 64, id 59205, offset 0, flags [DF], proto TCP (6), length 2920)
    intranet.arpol.pl.ldaps > gateway.26252: Flags [.], cksum 0x54b9 (incorrect -> 0xce31), seq 1:2881, ack 166, win 237, length 2880
    12:04:46.744789 IP (tos 0x0, ttl 64, id 59207, offset 0, flags [DF], proto TCP (6), length 2355)
    intranet.arpol.pl.ldaps > gateway.26252: Flags [P.], cksum 0x5284 (incorrect -> 0x9f7e), seq 2881:5196, ack 166, win 237, length 2315
    12:04:46.775384 IP (tos 0x0, ttl 51, id 61002, offset 0, flags [DF], proto TCP (6), length 40)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [.], cksum 0xcda9 (correct), seq 166, ack 1441, win 32, length 0
    12:04:46.775470 IP (tos 0x0, ttl 51, id 61003, offset 0, flags [DF], proto TCP (6), length 40)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [.], cksum 0xbef7 (correct), seq 166, ack 5196, win 39, length 0
    12:04:46.778483 IP (tos 0x0, ttl 51, id 61004, offset 0, flags [DF], proto TCP (6), length 47)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x74e3 (correct), seq 166:173, ack 5196, win 39, length 7
    12:04:46.778773 IP (tos 0x0, ttl 64, id 59209, offset 0, flags [DF], proto TCP (6), length 40)
    intranet.arpol.pl.ldaps > gateway.26252: Flags [F.], cksum 0x4979 (incorrect -> 0xbe29), seq 5196, ack 173, win 237, length 0
    12:04:46.779532 IP (tos 0x0, ttl 51, id 61005, offset 0, flags [DF], proto TCP (6), length 40)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [F.], cksum 0xbeef (correct), seq 173, ack 5196, win 39, length 0
    12:04:46.779545 IP (tos 0x0, ttl 64, id 59210, offset 0, flags [DF], proto TCP (6), length 40)
    intranet.arpol.pl.ldaps > gateway.26252: Flags [.], cksum 0x4979 (incorrect -> 0xbe28), seq 5197, ack 174, win 237, length 0
    12:04:46.808967 IP (tos 0x0, ttl 51, id 61006, offset 0, flags [DF], proto TCP (6), length 40)
    gateway.26252 > intranet.arpol.pl.ldaps: Flags [.], cksum 0xbeee (correct), seq 174, ack 5197, win 39, length 0


    and from from local network (succesful):
    12:04:13.860771 IP (tos 0x0, ttl 64, id 30826, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [S], cksum 0xfac3 (correct), seq 270120086, win 29200, options [mss 1460,sackOK,TS val 280415484 ecr 0,nop,wscale 7], length 0
    12:04:13.860803 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [S.], cksum 0x49b3 (incorrect -> 0x6119), seq 280388576, ack 270120087, win 28960, options [mss 1460,sackOK,TS val 358813840 ecr 280415484,nop,wscale 7], length 0
    12:04:13.861079 IP (tos 0x0, ttl 64, id 30827, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [.], cksum 0x49ab (incorrect -> 0x0021), seq 1, ack 1, win 229, options [nop,nop,TS val 280415484 ecr 358813840], length 0
    12:04:13.874634 IP (tos 0x0, ttl 64, id 30828, offset 0, flags [DF], proto TCP (6), length 284)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x4a93 (incorrect -> 0x5d37), seq 1:233, ack 1, win 229, options [nop,nop,TS val 280415487 ecr 358813840], length 232
    12:04:13.874653 IP (tos 0x0, ttl 64, id 29553, offset 0, flags [DF], proto TCP (6), length 52)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [.], cksum 0x49ab (incorrect -> 0xff21), seq 1, ack 233, win 235, options [nop,nop,TS val 358813854 ecr 280415487], length 0
    12:04:13.877408 IP (tos 0x0, ttl 64, id 29554, offset 0, flags [DF], proto TCP (6), length 5247)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [P.], cksum 0x5df6 (incorrect -> 0x3816), seq 1:5196, ack 233, win 235, options [nop,nop,TS val 358813856 ecr 280415487], length 5195
    12:04:13.877582 IP (tos 0x0, ttl 64, id 30829, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [.], cksum 0x49ab (incorrect -> 0xea88), seq 233, ack 5196, win 310, options [nop,nop,TS val 280415488 ecr 358813856], length 0
    12:04:13.878882 IP (tos 0x0, ttl 64, id 30830, offset 0, flags [DF], proto TCP (6), length 127)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x49f6 (incorrect -> 0x5d06), seq 233:308, ack 5196, win 310, options [nop,nop,TS val 280415488 ecr 358813856], length 75
    12:04:13.878921 IP (tos 0x0, ttl 64, id 30831, offset 0, flags [DF], proto TCP (6), length 103)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x49de (incorrect -> 0x7cce), seq 308:359, ack 5196, win 310, options [nop,nop,TS val 280415488 ecr 358813856], length 51
    12:04:13.880274 IP (tos 0x0, ttl 64, id 29558, offset 0, flags [DF], proto TCP (6), length 52)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [.], cksum 0x49ab (incorrect -> 0xea52), seq 5196, ack 359, win 235, options [nop,nop,TS val 358813859 ecr 280415488], length 0
    12:04:13.880407 IP (tos 0x0, ttl 64, id 29559, offset 0, flags [DF], proto TCP (6), length 103)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [P.], cksum 0x49de (incorrect -> 0xf4ae), seq 5196:5247, ack 359, win 235, options [nop,nop,TS val 358813859 ecr 280415488], length 51
    12:04:13.881359 IP (tos 0x0, ttl 64, id 30832, offset 0, flags [DF], proto TCP (6), length 95)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x49d6 (incorrect -> 0xcf1a), seq 359:402, ack 5247, win 310, options [nop,nop,TS val 280415489 ecr 358813859], length 43
    12:04:13.881527 IP (tos 0x0, ttl 64, id 29560, offset 0, flags [DF], proto TCP (6), length 95)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [P.], cksum 0x49d6 (incorrect -> 0x9617), seq 5247:5290, ack 402, win 235, options [nop,nop,TS val 358813861 ecr 280415489], length 43
    12:04:13.883050 IP (tos 0x0, ttl 64, id 30833, offset 0, flags [DF], proto TCP (6), length 88)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x49cf (incorrect -> 0xb46f), seq 402:438, ack 5290, win 310, options [nop,nop,TS val 280415489 ecr 358813861], length 36
    12:04:13.883063 IP (tos 0x0, ttl 64, id 30834, offset 0, flags [DF], proto TCP (6), length 83)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [P.], cksum 0x49ca (incorrect -> 0x37a7), seq 438:469, ack 5290, win 310, options [nop,nop,TS val 280415489 ecr 358813861], length 31
    12:04:13.883082 IP (tos 0x0, ttl 64, id 30835, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [F.], cksum 0x49ab (incorrect -> 0xe937), seq 469, ack 5290, win 310, options [nop,nop,TS val 280415489 ecr 358813861], length 0
    12:04:13.883155 IP (tos 0x0, ttl 64, id 29561, offset 0, flags [DF], proto TCP (6), length 52)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [.], cksum 0x49ab (incorrect -> 0xe981), seq 5290, ack 470, win 235, options [nop,nop,TS val 358813862 ecr 280415489], length 0
    12:04:13.883226 IP (tos 0x0, ttl 64, id 29562, offset 0, flags [DF], proto TCP (6), length 52)
    intranet.arpol.pl.ldaps > 192.168.100.39.60616: Flags [F.], cksum 0x49ab (incorrect -> 0xe980), seq 5290, ack 470, win 235, options [nop,nop,TS val 358813862 ecr 280415489], length 0
    12:04:13.883338 IP (tos 0x0, ttl 64, id 8121, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.100.39.60616 > intranet.arpol.pl.ldaps: Flags [.], cksum 0xe934 (correct), seq 470, ack 5291, win 310, options [nop,nop,TS val 280415490 ecr 358813862], length 0


    Where is the mistake?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 14 2017, 07:12 PM - #Permalink
    Resolved
    0 votes
    Thanks Nick. That worked perfectly.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 12 2017, 08:55 AM - #Permalink
    Resolved
    0 votes
    You may need to export the CA certificate ca-cert.pem to machines using ldaps.

    The hack to the /etc/init/d/slapd file should be quite easy. Change line 83 to:
    harg="$harg ldaps://$LANIP/ ldap://$LANIP/"
    and similarly change line 87 to:
    harg="$harg ldaps://$IP/ ldap://$IP/
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 12 2017, 02:34 AM - #Permalink
    Resolved
    0 votes
    ok. I would say i am fairly lost.

    I looked at /etc/init.d/slapd , and i was not sure where to make the change to switch to ldap from ldaps. Also, i found that comparing 5.2 and 6.8 files is pretty pointless since a lot changed between the two, at least that is what it looks like to my untrained eye.

    So, i went back to trying to implement ldaps. For a while i thought that i had to create my own certificate, but then i started thinking that the certificate is already created, and installed on clearos by default. That is what it looks like in slapd. Is that true? which certificate would i export and apply to the other machines (e.g. jenkins)? Is that necessary?

    Where else would i look for issues in implementing ldaps.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, February 11 2017, 04:44 PM - #Permalink
    Resolved
    0 votes
    In 5.x and 6.x (and probably 7.x), ldap:389 is for localhost only; ldaps:636 is for LAN. The file /etc/init.d/slapd can be hacked to allow ldap:389 for the LAN as well.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, February 11 2017, 01:56 PM - #Permalink
    Resolved
    0 votes
    Thanks. Nick. I read on forums that for the local network ldap is ok, and there was no need for ldaps. ldaps is only used for external connections - unless I misread. Since most (all) of our ldap traffic happens when the user vpns or is on site, does it still need to be ldaps.

    I did no hacking / shortcuts. I am trying to get defaults going.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, February 11 2017, 07:31 AM - #Permalink
    Resolved
    0 votes
    Unless you've hacked your start-up file you need to use ldaps which is on port 636 and not ldap:389.
    The reply is currently minimized Show
Your Reply