rmd: (trinity keyboard)
[personal profile] rmd
So, LDAP. And NAT.
When something connects to an LDAP server, does it identify/authenticate itself via something in the actual LDAP connection? Or does the LDAP server rely on the source IP of the connecting host to figure out if the client is or can get to privileged objects?

I'm pretty sure it's IP-based

Date: 2011-06-20 02:04 pm (UTC)
drwex: (Default)
From: [personal profile] drwex
Or can be set up to restrict that way. I'm not sure if it supports other forms of restriction.

Date: 2011-06-20 03:02 pm (UTC)
ceo: (Default)
From: [personal profile] ceo
The all-knowing Wikipedia sez:
The Bind operation authenticates the client to the server. Simple Bind can send the user's DN and password in plaintext, so the connection should be protected using Transport Layer Security (TLS). The server typically checks the password against the userPassword attribute in the named entry. Anonymous Bind (with empty DN and password) resets the connection to anonymous state. SASL (Simple Authentication and Security Layer) Bind provides authentication services through a wide range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.

Bind also sets the LDAP protocol version. The version is an integer and at present must be either 2 (two) or 3 (three), although the standard supports integers between 1 and 127 (inclusive) in the protocol. If the client requests a version that the server does not support, the server must set the result code in the bind response to the code for a protocol error. Normally clients should use LDAPv3, which is the default in the protocol but not always in LDAP libraries.

Bind had to be the first operation in a session in LDAPv2, but is not required in LDAPv3 (the current LDAP version).

Date: 2011-06-20 03:17 pm (UTC)
From: [identity profile] i-leonardo.livejournal.com
it's configuration dependent. in Your Employer's case, at least when i left, anonymous binds are permitted from on-campus (based on their IP addr range) but were only permitted to see "public" data. as ghastly as it sounds, non-SSL authenticating binds ARE permitted ! so be careful where you type your password, eugene. an application, like the dhcp registration app, can see retrieve un-published user data IF they have an application LDAP entry with its own paswword. when an app needs to authenticate a user, it asks the user to supply their uname and password. the app binds to LDAP (SSL), authenticates itself, uses the uname to search for the user's DN (not the same as the uname), and releases the connection. then it attempts to bind again, this time using the user's DN and password.

Date: 2011-06-20 03:32 pm (UTC)
From: [identity profile] dfjdejulio.livejournal.com
We don't use that namby-pamby password-based auth *here* -- we use kerberos-authenticated LDAP binds. (But there's tons of options.)

Profile

rmd: (Default)
rmd

June 2025

S M T W T F S
1234567
89 1011121314
15161718192021
22232425262728
2930     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 20th, 2026 04:38 pm
Powered by Dreamwidth Studios