search for: bindresponse

...nting Ticket) request and response. > There is no details about the AS (authentication service) request. Therefore it's difficult to find the problem cause. > > Maybe the LDAP part is easier to solve. Although the TCP dump does not show much details it indicates the problem: > "bindResponse(3) strongAuthRequired (SASL:[GSS-SPNEGO]: Sign or Seal are required" > Basically the LDAP Server requires a secured connection. > > This is related to following SAMBA settings: > >ldap server require strong auth (G) > > > >The ldap server require strong auth defines...

...and response. > > There is no details about the AS (authentication service) request. Therefore it's difficult to find the problem cause. > > > > Maybe the LDAP part is easier to solve. Although the TCP dump does not show much details it indicates the problem: > > "bindResponse(3) strongAuthRequired (SASL:[GSS-SPNEGO]: Sign or Seal are required" > > Basically the LDAP Server requires a secured connection. > > > > This is related to following SAMBA settings: > > > ldap server require strong auth (G) > > > > > > The ldap s...

...e. >>> There is no details about the AS (authentication service) request. Therefore it's difficult to find the problem cause. >>> >>> Maybe the LDAP part is easier to solve. Although the TCP dump does not show much details it indicates the problem: >>> "bindResponse(3) strongAuthRequired (SASL:[GSS-SPNEGO]: Sign or Seal are required" >>> Basically the LDAP Server requires a secured connection. >>> >>> This is related to following SAMBA settings: >>>> ldap server require strong auth (G) >>>> >>>...

Mandi! Andrew Bartlett via samba In chel di` si favelave... > > This mean that the printer try to auth in LDAP 'plain' (no SSL, no > > TLS), and so samba refuse that? > No, it means that Samba is refusing to accept a NTLM or Kerberos > authenticated connection without SIGN or SEAL negotiated, as an > attacker could take over an unprotected network connection and do

...1 62.787008 10.0.31.235 -> 10.0.5.0 TCP 66 43054 > ldap [ACK] Seq=1 Ack=1 Win=14624 Len=0 TSval=536265719 TSecr=0 62.787039 10.0.31.235 -> 10.0.5.0 LDAP 122 bindRequest(1) "CN=stampa,CN=Users,DC=galliera,DC=it" simple 62.788484 10.0.5.0 -> 10.0.31.235 LDAP 88 bindResponse(1) success 62.788528 10.0.31.235 -> 10.0.5.0 TCP 66 43053 > ldap [ACK] Seq=57 Ack=23 Win=14624 Len=0 TSval=536265719 TSecr=36040952 62.789334 10.0.5.0 -> 10.0.31.235 LDAP 88 bindResponse(1) success 62.789365 10.0.31.235 -> 10.0.5.0 TCP 66 43054 > ldap [ACK] Seq=57 A...

...olleagues today where almost all logins where failing or excessively delayed, while the LDAP database itself was pretty fast. They run Dovecot 1.2.11 (yes, I know, stoneage) against an LDAP server run by a 3rd party, auth_bind=yes (required). The problem is that this third party LDAP server delays bindResponse 3 seconds when the password is wrong. A user wanted to login every 2-3 seconds this morning with the wrong password, which effectively killed the system because the LDAP connection was mostly stalled waiting for the auth timeout. >From a previous discussion with Timo I know that bindRequests ca...

...=361924284 4 0.003849 10.5.1.202 -> 10.5.1.25 LDAP 80 bindRequest(1) "<ROOT>" simple 5 0.003857 10.5.1.25 -> 10.5.1.202 TCP 66 389→40258 [ACK] Seq=1 Ack=15 Win=29056 Len=0 TSval=361924285 TSecr=121084504 6 0.005388 10.5.1.25 -> 10.5.1.202 LDAP 80 bindResponse(1) success 7 0.005536 10.5.1.202 -> 10.5.1.25 TCP 66 40258→389 [ACK] Seq=15 Ack=15 Win=5840 Len=0 TSval=121084504 TSecr=361924285 8 0.023918 10.5.1.202 -> 10.5.1.25 LDAP 183 searchRequest(2) "<ROOT>" baseObject 9 0.024364 10.5.1.25 -> 10.5.1.202...

...t shown in the packet capture as displayed by tshark: $ tshark -o tcp.check_checksum:FALSE -tr -r dc2.pcap 1 0.000000 172.17.50.13 -> 172.17.10.2 LDAP 197 bindRequest(7) "CN=DovecotSvc,OU=Svcs,DC=office,DC=on2it,DC=net" simple 2 0.001879 172.17.10.2 -> 172.17.50.13 LDAP 88 bindResponse(7) success Yay! The service account binds just fine. 3 0.001967 172.17.50.13 -> 172.17.10.2 LDAP 180 searchRequest(8) "dc=office,dc=on2it,dc=net" wholeSubtree 4 0.002772 172.17.10.2 -> 172.17.50.13 LDAP 502 searchResEntry(8) "CN=Jeroen Scheerder,OU=Users,DC=office,DC...

...2489669 94 1263.254227 10.5.1.202 -> 10.5.1.25 LDAP 80 bindRequest(1) "<ROOT>" simple 95 1263.254236 10.5.1.25 -> 10.5.1.202 TCP 66 389→40994 [ACK] Seq=1 Ack=15 Win=29056 Len=0 TSval=2012489671 TSecr=89621947 96 1263.255860 10.5.1.25 -> 10.5.1.202 LDAP 80 bindResponse(1) success 97 1263.256002 10.5.1.202 -> 10.5.1.25 TCP 66 40994→389 [ACK] Seq=15 Ack=15 Win=5840 Len=0 TSval=89621947 TSecr=2012489671 98 1263.303918 10.5.1.202 -> 10.5.1.25 LDAP 183 searchRequest(2) "<ROOT>" baseObject 99 1263.304298 10.5.1.25 -> 10.5.1.20...

Mandi! Andrew Bartlett via samba In chel di` si favelave... > > There's some way to ''tight'' that configuration , eg permit 'ldap server require strong auth = > > no' only by some hosts? > > Or some other smb.conf options that i've missed? > Nothing at this stage. Ok. > The issue is that they need to do fully signed or sealed Kerberos

I suspect the problem is that dovecot tries to report LDAP error over GSSAPI. So the best fix is to make sure your LDAP server does not return error. =) Aki On 15.8.2019 14.56, Eugene Bright wrote: > That's right. > GSS-API is not used anywhere else. > Do you like to inspect my full configuration? > I can dump connection session and send pcap file here. > > On August 15,

...0.074684 10.5.1.202 -> 10.5.1.25 LDAP 1555 bindRequest(3) "<ROOT>" sasl > 12 0.074698 10.5.1.25 -> 10.5.1.202 TCP 66 389→40258 [ACK] Seq=168 Ack=1621 Win=32000 Len=0 TSval=361924302 TSecr=121084518 > 13 0.079764 10.5.1.25 -> 10.5.1.202 LDAP 270 bindResponse(3) success > > and clearly this is an example of SASL over PLAIN LDAP, no TLS nor > SSL, because i can ''see'' the query (if it was TLS/SSL, i'll see the > SSL/TLS handshake and the only 'data'.) > > So seems that my MFP use plain SASL, and so i'...

I see nothing suspicious in FreeIPA slapd logs because connection drops before SASL negotiation completion. Network analysis shows client sending RST after receiving `bindResponse(7) saslBindInProgress`. On 8/15/19 3:07 PM, Aki Tuomi via dovecot wrote: > I suspect the problem is that dovecot tries to report LDAP error over GSSAPI. So the best fix is to make sure your LDAP server does not return error. =) > > Aki > > On 15.8.2019 14.56, Eugene Bright wrote:...

Hi Rowland, Sorry to inform that none of thus packages solve my problem. But today, with some Tranquil.it helps, I have some news: - Upgrade from 4.11.14 -> 4.12.9 is OK - Upgrade from 4.12.9 -> 4.13.2 : problem is present with Tranquil.it AND Louis package - Fresh install + member join with 4.13.2 is OK (Centos AND Buster packages) Problem only occur when upgrading member to 4.13.2 with