You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently deployed to an environment with "bad" DNS entries for their Active Directory (yikes). These resulted in referrals to addresses in the 169.254 space, which, obviously, would not respond with any kind of LDAP server response.
dig DomainDnsZones.example.com | grep 169
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 169, AUTHORITY: 0, ADDITIONAL: 1
DomainDnsZones.example.com. 600 IN A 169.254.201.143
We have a pcap trace, which shows good searchResRefs returned from the actual LDAP server...
Obviously, we'll get the customer to correct their DNS entries, but I have a log showing a 17-minute wait between connecting and receiving an exception from the library. The exception has no stack trace, so I suspect there's another issue where this exception is raised, but I can't quite track it down in the library code yet (we're on version 3.6.0).
You should notice the object disposed exception when calling StopTls, too, which shouldn't be possible barring race conditions in the library code (see our usage later). I'm happy to write this up as a separate issue.
2022-02-07T14:06:34.299682000Z info: Example.Security.Authentication.Ldap.LdapHandler[12]
2022-02-07T14:06:34.300251000Z AuthenticationScheme: LDAP was challenged.
2022-02-07T14:06:34.300583000Z trce: Example.Auditing[0]
2022-02-07T14:06:34.300946000Z (unauthenticated) [::ffff:10.92.44.19]: POST /external-login?returnurl=%2F returned 302
2022-02-07T14:06:34.301274000Z UserLogIn: [Identity] Starts an external log in.
2022-02-07T14:06:34.397019000Z trce: Example.Auditing[0]
2022-02-07T14:06:34.397416000Z (unauthenticated) [::ffff:10.92.44.19]: GET /ldap?state=<redacted>&returnUrl=%2Fexternal-login-callback%3Freturnurl%3D%252F&redirectUrl=%2Fsignin-ldap returned 200
2022-02-07T14:06:34.397748000Z UserLogIn: [Identity] Gets the LDAP log in view.
2022-02-07T14:06:52.553833000Z dbug: Example.Platform.Net.Ldap.NovellLdapConnectionFactory[0]
2022-02-07T14:06:52.554371000Z Connected to ldap://example.com:389
2022-02-07T14:23:51.421790000Z fail: Example.Ldap.NovellLdapSignInManager[0]
2022-02-07T14:23:51.422374000Z Error authenticating
2022-02-07T14:23:51.422831000Z LdapException: Operations Error (1) Operations Error
2022-02-07T14:23:51.423271000Z LdapException: Server Message: 000004DC: LdapErr: DSID-0C090A5C, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563
2022-02-07T14:23:51.423732000Z LdapException: Matched DN:
2022-02-07T14:23:51.424157000Z trce: Example.Auditing[0]
2022-02-07T14:23:51.424560000Z (unauthenticated) [::ffff:10.92.44.19]: POST /ldap returned 200
2022-02-07T14:23:51.424975000Z UserLogIn: [Identity] Log in via LDAP with a uid and password.
2022-02-07T14:23:51.425399000Z Exception: Cannot access a disposed object.
2022-02-07T14:23:51.425790000Z Object name: 'System.Net.Sockets.TcpClient'.
2022-02-07T14:23:51.426192000Z fail: Microsoft.AspNetCore.Server.Kestrel[13]
2022-02-07T14:23:51.426590000Z Connection id "0HMF7VAO5FKP8", Request id "0HMF7VAO5FKP8:00000003": An unhandled exception was thrown by the application.
2022-02-07T14:23:51.427004000Z System.ObjectDisposedException: Cannot access a disposed object.
2022-02-07T14:23:51.427442000Z Object name: 'System.Net.Sockets.TcpClient'.
2022-02-07T14:23:51.427839000Z at System.Net.Sockets.TcpClient.<ThrowIfDisposed>g__ThrowObjectDisposedException|65_0()
2022-02-07T14:23:51.428231000Z at System.Net.Sockets.TcpClient.GetStream()
2022-02-07T14:23:51.428633000Z at Novell.Directory.Ldap.Connection.StopTls()
2022-02-07T14:23:51.429037000Z at Novell.Directory.Ldap.LdapConnection.StopTls()
2022-02-07T14:23:51.429438000Z at Example.Platform.Net.Ldap.NovellLdapConnectionFactory.Use[T](Func`2 action) in /build/source/common/platform/Net/Ldap/NovellLdapConnectionFactory.cs:line 89
2022-02-07T14:23:51.429816000Z at Example.Ldap.NovellLdapSignInManager.SignInAsync(String username, String password) in /build/source/services/example/Ldap/NovellLdapSignInManager.cs:line 30
2022-02-07T14:23:51.430224000Z at Example.Ldap.Controllers.IdentityController.Ldap(LdapViewModel model) in /build/source/services/example/Ldap/Controllers/IdentityController.cs:line 52
2022-02-07T14:23:51.430668000Z at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
2022-02-07T14:23:51.431197000Z at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
2022-02-07T14:23:51.431595000Z at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
2022-02-07T14:23:51.431963000Z at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
2022-02-07T14:23:51.432293000Z at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
2022-02-07T14:23:51.432614000Z at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
We use the library roughly like this (unwound our private library calls for brevity)
We recently deployed to an environment with "bad" DNS entries for their Active Directory (yikes). These resulted in referrals to addresses in the 169.254 space, which, obviously, would not respond with any kind of LDAP server response.
We have a pcap trace, which shows good
searchResRef
s returned from the actual LDAP server...Obviously, we'll get the customer to correct their DNS entries, but I have a log showing a 17-minute wait between connecting and receiving an exception from the library. The exception has no stack trace, so I suspect there's another issue where this exception is raised, but I can't quite track it down in the library code yet (we're on version 3.6.0).
You should notice the object disposed exception when calling StopTls, too, which shouldn't be possible barring race conditions in the library code (see our usage later). I'm happy to write this up as a separate issue.
We use the library roughly like this (unwound our private library calls for brevity)
The text was updated successfully, but these errors were encountered: