sometimes login issue using ldap users

[saleht]

Dear Mark,

ave you tried scripting a bunch of ldapsearch queries to see if you can use that to reproduce the same issue from the machine hosting the OMERO server? How do those queries go?

yes, i did and it works fine, i can not reproduce this issue using ldap
i did loop from 150 ldapsearch request in python, i can upload my script if you want also to check it if it simulate omero, but i think ldapsearch is different in behavior from omero log in request, because i think in ldap search every time new connection will be established , thats my understanding maybe wrong

i think the problem it something related with this link, but i don't have much experience in Java Environment
http://docs.oracle.com/javase/jndi/tuto ... /pool.html

and i will upload two log file from wire shark in both situation
when it works and when it is not

cheers
Saleh

[jmoore]

Hi Saleh,

can you show us an example of your ldapsearch usage as well as your current LDAP/OMERO configuration (omitting passwords of course)?

~Josh.

[saleht]

python script is just to call for username and it will send back the email address, i think this is similar to Auth functionally

Code: Select all

###### this for testing purpose, test AD respone
# Author: Saleh Tibi   
# Date:   18.06.17


# -*- coding: utf-7 -*-
import ldap
import sys
import time


#############################################################
# func that pass it a ldap query and it gives back rows
def ldap_search(lquery):
  try:
   ldap_base='OU=IDMUsers,DC=AD,DC=hhu,DC=de'
   l=ldap.initialize("ldap://ldaps.ad.hhu.de:389/")
   l.protocol_version = ldap.VERSION3
   username="XXXXXXX@ad.hhu.de"
   password="XXXXXXXXXXXXXXXX"
   l.simple_bind(username, password)
   time.sleep(1)
   search_scope = ldap.SCOPE_SUBTREE
   retrieve_attributes = ["mail"]
   
   ldap_result_id = l.search(
   ldap_base,
   search_scope,
   lquery,
   retrieve_attributes)
   
   result_set = []
   
   while 1:
        result_type, result_data = l.result(ldap_result_id,0)
        if (result_data == []):
            break
        else:
           
            ## otherwise you can just wait until the initial result and break out
            if result_type == ldap.RES_SEARCH_ENTRY:
                result_set.append(result_data)
                 
   return result_set
   l.unbind()
  except ldap.LDAPError, e:
    print e   
###########################################################################   

def main():
    count=0
    i="saleht"
    print (i)
    a="(sAMAccountName="+i+")"
    for x in range (1,150):
      g=ldap_search(a)
      if (g != []):
         f= g[0]
         g1=f[0]
         g3= g1[1].get('mail')
         g4=g3[0]
         print (g4)
         count=count+1
    print(count)
     
if __name__ == '__main__':
    sys.exit(main())

this is my test server, issue reproducible on both servers
bin/omero config get --hide-password

Code: Select all

omero.data.dir=/data/OMERO
omero.db.name=omero_database
omero.db.pass=********
omero.db.user=db_user
omero.ldap.base=dc=ad,dc=hhu,dc=de
omero.ldap.config=true
omero.ldap.new_user_group=default
omero.ldap.password=********
omero.ldap.referral=follow
omero.ldap.urls=ldap://ldaps.ad.hhu.de:389
omero.ldap.user_mapping=omeName=sAMAccountName,firstName=givenName,lastName=sn,email=mail
omero.ldap.username=SVC_Omero
omero.security.ignore_case=true
omero.web.wsgi_timeout=60
omero.web.wsgi_workers=5


[saleht]

some wireshark sniffing :
login success:
Omero ip is 134.99.190.12
ldap ip is LdapIpAddress

Code: Select all

No.     Time           Source                Destination           Protocol Length Info
    163 9.719970151    134.99.190.12         LdapIpAddress       LDAP     190    searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree

Frame 163: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) on interface 0
Ethernet II, Src: Vmware_b4:91:6c (00:50:56:b4:91:6c), Dst: Oracle_30:d0:26 (00:21:28:30:d0:26)
Internet Protocol Version 4, Src: 134.99.190.12 (134.99.190.12), Dst: LdapIpAddress (LdapIpAddress)
Transmission Control Protocol, Src Port: 43520 (43520), Dst Port: msft-gc (3268), Seq: 1, Ack: 1, Len: 124
Lightweight Directory Access Protocol
    LDAPMessage searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree
        messageID: 3
        protocolOp: searchRequest (3)
            searchRequest
                baseObject: dc=XX,dc=Xx,dc=de
                scope: wholeSubtree (2)
                derefAliases: derefAlways (3)
                sizeLimit: 0
                timeLimit: 0
                typesOnly: False
                Filter: (&(objectClass=person)(sAMAccountName=saleht))
                    filter: and (0)
                        and: (&(objectClass=person)(sAMAccountName=saleht))
                            and: 2 items
                                Filter: (objectClass=person)
                                    and item: equalityMatch (3)
                                        equalityMatch
                                            attributeDesc: objectClass
                                            assertionValue: person
                                Filter: (sAMAccountName=saleht)
                                    and item: equalityMatch (3)
                                        equalityMatch
                                            attributeDesc: sAMAccountName
                                            assertionValue: saleht
                attributes: 0 items
        [Response In: 170]
        controls: 1 item

No.     Time           Source                Destination           Protocol Length Info
    164 9.722301578    LdapIpAddress        134.99.190.12         TCP      1514   [TCP segment of a reassembled PDU]

Frame 164: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Ethernet II, Src: Oracle_30:d0:26 (00:21:28:30:d0:26), Dst: Vmware_b4:91:6c (00:50:56:b4:91:6c)
Internet Protocol Version 4, Src: LdapIpAddress (LdapIpAddress), Dst: 134.99.190.12 (134.99.190.12)
Transmission Control Protocol, Src Port: msft-gc (3268), Dst Port: 43520 (43520), Seq: 1, Ack: 125, Len: 1448

No.     Time           Source                Destination           Protocol Length Info
    165 9.722339828    134.99.190.12         LdapIpAddress        TCP      66     43520 > msft-gc [ACK] Seq=125 Ack=1449 Win=333 Len=0 TSval=220917 TSecr=1721539786

Frame 165: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Ethernet II, Src: Vmware_b4:91:6c (00:50:56:b4:91:6c), Dst: Oracle_30:d0:26 (00:21:28:30:d0:26)
Internet Protocol Version 4, Src: 134.99.190.12 (134.99.190.12), Dst: LdapIpAddress (LdapIpAddress)
Transmission Control Protocol, Src Port: 43520 (43520), Dst Port: msft-gc (3268), Seq: 125, Ack: 1449, Len: 0

No.     Time           Source                Destination           Protocol Length Info
    166 9.722423984    134.99.108.149        134.99.190.12         TCP      1514   [TCP segment of a reassembled PDU]

Frame 166: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Ethernet II, Src: Oracle_30:d0:26 (00:21:28:30:d0:26), Dst: Vmware_b4:91:6c (00:50:56:b4:91:6c)
Internet Protocol Version 4, Src: LdapIpAddress (LdapIpAddress), Dst: 134.99.190.12 (134.99.190.12)
Transmission Control Protocol, Src Port: msft-gc (3268), Dst Port: 43520 (43520), Seq: 1449, Ack: 125, Len: 1448

No.     Time           Source                Destination           Protocol Length Info
    167 9.722442290    134.99.190.12        LdapIpAddress        TCP      66     43520 > msft-gc [ACK] Seq=125 Ack=2897 Win=355 Len=0 TSval=220917 TSecr=1721539786

Frame 167: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Ethernet II, Src: Vmware_b4:91:6c (00:50:56:b4:91:6c), Dst: Oracle_30:d0:26 (00:21:28:30:d0:26)
Internet Protocol Version 4, Src: 134.99.190.12 (134.99.190.12), Dst: LdapIpAddress (LdapIpAddress)
Transmission Control Protocol, Src Port: 43520 (43520), Dst Port: msft-gc (3268), Seq: 125, Ack: 2897, Len: 0

No.     Time           Source                Destination           Protocol Length Info
    168 9.722448652    LdapIpAddress        134.99.190.12         TCP      1514   [TCP segment of a reassembled PDU]


login failed
Notice TCP Retransmission

Code: Select all

No.     Time           Source                Destination           Protocol Length Info
  24759 345.417022543  LdapIpAddress        LdapIpAddress        LDAP     190    searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree

Frame 24759: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) on interface 0
Ethernet II, Src: Vmware_b4:91:6c (00:50:56:b4:91:6c), Dst: Oracle_30:d0:26 (00:21:28:30:d0:26)
Internet Protocol Version 4, Src: 134.99.190.12 (134.99.190.12), Dst: LdapIpAddress (LdapIpAddress)
Transmission Control Protocol, Src Port: 51846 (51846), Dst Port: msft-gc (3268), Seq: 1, Ack: 1, Len: 124
Lightweight Directory Access Protocol
    LDAPMessage searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree

No.     Time           Source                Destination           Protocol Length Info
  24797 345.618747946  134.99.190.12        LdapIpAddress       LDAP     190   [color=#FF0000] [TCP Retransmission] searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree[/color]

Frame 24797: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) on interface 0
Ethernet II, Src: Vmware_b4:91:6c (00:50:56:b4:91:6c), Dst: Oracle_30:d0:26 (00:21:28:30:d0:26)
Internet Protocol Version 4, Src: 134.99.190.12 (134.99.190.12), Dst: LdapIpAddress (LdapIpAddress)
Transmission Control Protocol, Src Port: 51846 (51846), Dst Port: msft-gc (3268), Seq: 1, Ack: 1, Len: 124
Lightweight Directory Access Protocol
    LDAPMessage searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree
[color=#FF0000]
No.     Time           Source                Destination           Protocol Length Info
  24798 345.820770923  134.99.190.12         LdapIpAddress        LDAP     190    [TCP Retransmission] searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree [/color]


Frame 24798: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) on interface 0
Ethernet II, Src: Vmware_b4:91:6c (00:50:56:b4:91:6c), Dst: Oracle_30:d0:26 (00:21:28:30:d0:26)
Internet Protocol Version 4, Src: 134.99.190.12 (134.99.190.12), Dst: LdapIpAddress (LdapIpAddress)
Transmission Control Protocol, Src Port: 51846 (51846), Dst Port: msft-gc (3268), Seq: 1, Ack: 1, Len: 124
Lightweight Directory Access Protocol


[mtbc]

Dear Saleh,

Out of curiosity, does

Code: Select all

-Dcom.sun.jndi.ldap.read.timeout=5000

make any difference?

Cheers,
Mark

[mtbc]

I'm a bit confused by the,

Code: Select all

No.     Time           Source                Destination           Protocol Length Info
  24759 345.417022543  LdapIpAddress        LdapIpAddress        LDAP     190    searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree


which appears to capture the LDAP server talking to itself but in the failure case does it not look like the OMERO server is successfully sending queries out to the LDAP server and not receiving any response?

Cheers,
Mark

[saleht]

Dear Mark,

Out of curiosity, does

Code: Select all
-Dcom.sun.jndi.ldap.read.timeout=5000

make any difference?

unfortunately No
i added in /grid/template.xml file but still same issue

[saleht]

I'm a bit confused by the,

Code: Select all
No. Time Source Destination Protocol Length Info
24759 345.417022543 LdapIpAddress LdapIpAddress LDAP 190 searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree

No, this is my mistake. i just tried to hide my ldap ip address by changing the ip with this

this is the correct record

No. Time Source Destination Protocol Length Info
24759 345.417022543 134.99.190.12 LdapIpAddress LDAP 190 searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree

Saleh

[saleht]

OMERO server is successfully sending queries out to the LDAP server and not receiving any response?

Code: Select all

No.     Time           Source                Destination           Protocol Length Info
  24798 345.820770923  134.99.190.12         LdapIpAddress        LDAP     190    [TCP Retransmission] searchRequest(3) "dc=ad,dc=hhu,dc=de" wholeSubtree

i think the issue will solved when we discover, why OMEOR sending
[TCP Retransmission] searchRequest(3)

i am trying to read in internet, but there are many possibly

cheers
Saleh

[mtbc]

Dear Saleh,

I would naively guess that the networking stack knows that the link is fast -- indeed, the successful LDAP reply came back in nearly 2ms -- so it is retransmitting after over 200ms because by that time the lack of reply gives it good reason to think the original packet lost. A TCP expert may now come and correct me!

Cheers,
Mark