We're Hiring!

sometimes login issue using ldap users

Having a problem deploying OMERO? Please ask new questions at https://forum.image.sc/tags/omero
Please note:
Historical discussions about OMERO. Please look for and ask new questions at https://forum.image.sc/tags/omero

The OMERO.server installation documentation begins here and you can find OMERO.web deployment documentation here.

Re: sometimes login issue using ldap users

Postby saleht » Thu Jun 22, 2017 7:09 am

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 :D

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
Last edited by saleht on Thu Jun 22, 2017 7:52 am, edited 1 time in total.
saleht
 
Posts: 96
Joined: Wed Nov 16, 2016 1:06 pm

Re: sometimes login issue using ldap users

Postby jmoore » Thu Jun 22, 2017 7:24 am

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.
User avatar
jmoore
Site Admin
 
Posts: 1591
Joined: Fri May 22, 2009 1:29 pm
Location: Germany

Re: sometimes login issue using ldap users

Postby saleht » Thu Jun 22, 2017 9:19 am

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
 
Posts: 96
Joined: Wed Nov 16, 2016 1:06 pm

Re: sometimes login issue using ldap users

Postby saleht » Thu Jun 22, 2017 2:19 pm

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
saleht
 
Posts: 96
Joined: Wed Nov 16, 2016 1:06 pm

Re: sometimes login issue using ldap users

Postby mtbc » Thu Jun 22, 2017 2:31 pm

Dear Saleh,

Out of curiosity, does
Code: Select all
-Dcom.sun.jndi.ldap.read.timeout=5000
make any difference?

Cheers,
Mark
User avatar
mtbc
Team Member
 
Posts: 282
Joined: Tue Oct 23, 2012 10:59 am
Location: Dundee, Scotland

Re: sometimes login issue using ldap users

Postby mtbc » Thu Jun 22, 2017 2:47 pm

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
User avatar
mtbc
Team Member
 
Posts: 282
Joined: Tue Oct 23, 2012 10:59 am
Location: Dundee, Scotland

Re: sometimes login issue using ldap users

Postby saleht » Thu Jun 22, 2017 2:48 pm

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
 
Posts: 96
Joined: Wed Nov 16, 2016 1:06 pm

Re: sometimes login issue using ldap users

Postby saleht » Thu Jun 22, 2017 2:50 pm

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 :D

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
Last edited by saleht on Thu Jun 22, 2017 2:57 pm, edited 1 time in total.
saleht
 
Posts: 96
Joined: Wed Nov 16, 2016 1:06 pm

Re: sometimes login issue using ldap users

Postby saleht » Thu Jun 22, 2017 2:56 pm

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
saleht
 
Posts: 96
Joined: Wed Nov 16, 2016 1:06 pm

Re: sometimes login issue using ldap users

Postby mtbc » Thu Jun 22, 2017 3:54 pm

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
User avatar
mtbc
Team Member
 
Posts: 282
Joined: Tue Oct 23, 2012 10:59 am
Location: Dundee, Scotland

PreviousNext

Return to Installation and Deployment

Who is online

Users browsing this forum: No registered users and 1 guest