LDAP draft-wahl-ldap-session
HI! Recently I appreciated very much that some LDAP clients send the Session Track Control [1] along with their LDAP requests. draft-wahl-ldap-session was written especially with RADIUS in mind. Any chance to see this implemented? [1] https://tools.ietf.org/html/draft-wahl-ldap-session Unfortunately I'm not a C programmer so I can only give some pointers and promise to test the feature later. Example code in OpenLDAP tools: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=clients/too... I guess the structs are here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/l... Ciao, Michael.
On Jun 22, 2015, at 3:25 PM, Michael Ströder <michael@stroeder.com> wrote:
HI!
Recently I appreciated very much that some LDAP clients send the Session Track Control [1] along with their LDAP requests. draft-wahl-ldap-session was written especially with RADIUS in mind. Any chance to see this implemented?
So, what would be the session identifier in the case of Authentication (which is when rlm_ldap is being called)? -Arran
On Jun 22, 2015, at 3:38 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 22, 2015, at 3:25 PM, Michael Ströder <michael@stroeder.com> wrote:
HI!
Recently I appreciated very much that some LDAP clients send the Session Track Control [1] along with their LDAP requests. draft-wahl-ldap-session was written especially with RADIUS in mind. Any chance to see this implemented?
So, what would be the session identifier in the case of Authentication (which is when rlm_ldap is being called)?
Looks like it'd be username... Weird. I guess I can see the point. Are you sure OpenLDAP implements the server portion of this? -Arran
Arran Cudbard-Bell wrote:
On Jun 22, 2015, at 3:38 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 22, 2015, at 3:25 PM, Michael Ströder <michael@stroeder.com> wrote:
HI!
Recently I appreciated very much that some LDAP clients send the Session Track Control [1] along with their LDAP requests. draft-wahl-ldap-session was written especially with RADIUS in mind. Any chance to see this implemented?
So, what would be the session identifier in the case of Authentication (which is when rlm_ldap is being called)?
Looks like it'd be username... Weird. I guess I can see the point.
Yes, I think so.
Are you sure OpenLDAP implements the server portion of this?
Yes! I also make use of it in my web2ldap and in a password self-service application. It's nice to see the browser IP getting logged in syslog and even in the accesslog DB (when using slapo-accesslog). Ciao, Michael.
On 22 Jun 2015, at 16:22, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Jun 22, 2015, at 3:38 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 22, 2015, at 3:25 PM, Michael Ströder <michael@stroeder.com> wrote:
HI!
Recently I appreciated very much that some LDAP clients send the Session Track Control [1] along with their LDAP requests. draft-wahl-ldap-session was written especially with RADIUS in mind. Any chance to see this implemented?
So, what would be the session identifier in the case of Authentication (which is when rlm_ldap is being called)?
Looks like it'd be username... Weird. I guess I can see the point.
Yes, I think so.
Are you sure OpenLDAP implements the server portion of this?
Yes!
I also make use of it in my web2ldap and in a password self-service application. It's nice to see the browser IP getting logged in syslog and even in the accesslog DB (when using slapo-accesslog).
OK. Get to testing. v3.1.x branch only. Be sure to run at least 10k requests through it to check for memory leaks. I can see the controls going out in wireshark, though it can't decode them. You need to set: ldap { options { session_tracking = yes } } Depending on what's present in the request it'll include multiple controls (as per the RFC), one for User-Name, one for Acct-Session-ID, and one for Acct-Multi-Session-ID. NAS-IP-Address/NAS-IPv6-Address is used at the IP address, and the progname configuration item is used as the service name. I think we should fix that (using progname), but it works for testing. Maybe some sort of ${EXEC} syntax to allow us to call hostname on startup, and write the result somewhere. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Jun 23, 2015, at 12:45 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 22 Jun 2015, at 16:22, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Jun 22, 2015, at 3:38 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 22, 2015, at 3:25 PM, Michael Ströder <michael@stroeder.com> wrote:
HI!
Recently I appreciated very much that some LDAP clients send the Session Track Control [1] along with their LDAP requests. draft-wahl-ldap-session was written especially with RADIUS in mind. Any chance to see this implemented?
So, what would be the session identifier in the case of Authentication (which is when rlm_ldap is being called)?
Looks like it'd be username... Weird. I guess I can see the point.
Yes, I think so.
Are you sure OpenLDAP implements the server portion of this?
Yes!
I also make use of it in my web2ldap and in a password self-service application. It's nice to see the browser IP getting logged in syslog and even in the accesslog DB (when using slapo-accesslog).
OK. Get to testing. v3.1.x branch only. Be sure to run at least 10k requests through it to check for memory leaks.
Looks like older versions of libldap had a messed up declaration in ldap.h. I've added a work around for it, so if it previously didn't build, it should now. -Arran
On Jun 23, 2015, at 12:59 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 23, 2015, at 12:45 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 22 Jun 2015, at 16:22, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Jun 22, 2015, at 3:38 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 22, 2015, at 3:25 PM, Michael Ströder <michael@stroeder.com> wrote:
HI!
Recently I appreciated very much that some LDAP clients send the Session Track Control [1] along with their LDAP requests. draft-wahl-ldap-session was written especially with RADIUS in mind. Any chance to see this implemented?
So, what would be the session identifier in the case of Authentication (which is when rlm_ldap is being called)?
Looks like it'd be username... Weird. I guess I can see the point.
Yes, I think so.
Are you sure OpenLDAP implements the server portion of this?
Yes!
I also make use of it in my web2ldap and in a password self-service application. It's nice to see the browser IP getting logged in syslog and even in the accesslog DB (when using slapo-accesslog).
OK. Get to testing. v3.1.x branch only. Be sure to run at least 10k requests through it to check for memory leaks.
Looks like older versions of libldap had a messed up declaration in ldap.h. I've added a work around for it, so if it previously didn't build, it should now.
They didn't constify the formatOID argument, so you need to assign the preprocessor macros to non-const buffers to use them, wow... It's getting added to the list... Perl, anything related in any way to GNU, and libldap. They all need to die in fire. -Arran
Arran Cudbard-Bell wrote:
They didn't constify the formatOID argument, so you need to assign the preprocessor macros to non-const buffers to use them, wow...
Sorry, for that. I'm not a C programmer and using the control is so easy in Python. ;-)
It's getting added to the list... Perl, anything related in any way to GNU, and libldap. They all need to die in fire.
There's a long outstanding To-Do to clean up the C API mess in libldap. But I guess the more code exists which use this C API the less likely it gets. Ciao, Michael.
On Jun 23, 2015, at 3:46 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
They didn't constify the formatOID argument, so you need to assign the preprocessor macros to non-const buffers to use them, wow...
Sorry, for that. I'm not a C programmer and using the control is so easy in Python. ;-)
*sigh*
It's getting added to the list... Perl, anything related in any way to GNU, and libldap. They all need to die in fire.
There's a long outstanding To-Do to clean up the C API mess in libldap.
Minor things like correctly adding const qualifiers (which mark the variables or the things they point to as read-only) would help significantly.
But I guess the more code exists which use this C API the less likely it gets.
Ug. They should keep RFC draft compatibility (maybe as a layer on top of the rest of the API), and the rest should be refactored to something sane. You can't just keep piling shit on shit and expect it to turn into chocolate sprinkles. -Arran
Any progress on the testing? I'll have to remove the code unless it's confirmed to be working. -Arran
Michael Ströder wrote:
Arran Cudbard-Bell wrote:
Any progress on the testing?
I'll have to remove the code unless it's confirmed to be working.
I was pretty busy during the last days. Please give me two more days.
I'm testing git v3.1.x 36e1b02e926df5cd75d4d548694401535c607ca9. I'm simply using PAP with hashed passwords in LDAP attribute 'userPassword' (EAP-TTLS with PAP in real life, simple PAP here). Good, the search requests (conn=1044) contain the Session Tracking Control (OpenLDAP logs): 2015-06-29T10:47:05.316040+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=1 [IP=10.1.1.5 NAME=radiusd USERNAME=michael-homelan] SRCH base="cn=radiusd,ou=services,dc=stroeder,dc=local" scope=2 deref=0 filter="(uid=michael-homelan)" 2015-06-29T10:47:05.316051+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=1 [IP=10.1.1.5 NAME=radiusd USERNAME=michael-homelan] SRCH attr=userPassword radiusControlAttribute radiusRequestAttribute radiusReplyAttribute 2015-06-29T10:47:05.316244+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=1 [IP=10.1.1.5 NAME=radiusd USERNAME=michael-homelan] SEARCH RESULT tag=101 err=0 nentries=1 text= It seems an additional LDAP connection conn=1045 is opened: 2015-06-29T10:47:05.317153+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 fd=23 ACCEPT from IP=127.0.0.1:53074 (IP=0.0.0.0:1390) 2015-06-29T10:47:05.317219+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 op=0 BIND dn="uid=radiusd,ou=sys,dc=stroeder,dc=local" method=128 2015-06-29T10:47:05.324982+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 op=0 BIND dn="uid=radiusd,ou=sys,dc=stroeder,dc=local" mech=SIMPLE ssf=0 2015-06-29T10:47:05.325582+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 op=0 RESULT tag=97 err=0 text= But now for checking the password there is no Session Tracking Control sent along with the bind request (conn=1044, err=49 is ok because I deliberately used a wrong password): 2015-06-29T10:47:05.325647+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=2 BIND anonymous mech=implicit ssf=0 2015-06-29T10:47:05.325697+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=2 BIND dn="uid=michael-homelan,cn=radiusd,ou=services,dc=stroeder,dc=local" method=128 2015-06-29T10:47:05.330285+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=2 RESULT tag=97 err=49 text= But especially the client's IP address is interesting when looking for password brute-force attacks hence the Session Tracking control should also be sent along with the bind request. Ciao, Michael.
On 29 Jun 2015, at 04:56, Michael Ströder <michael@stroeder.com> wrote:
Michael Ströder wrote:
Arran Cudbard-Bell wrote:
Any progress on the testing?
I'll have to remove the code unless it's confirmed to be working.
I was pretty busy during the last days. Please give me two more days.
I'm testing git v3.1.x 36e1b02e926df5cd75d4d548694401535c607ca9.
I'm simply using PAP with hashed passwords in LDAP attribute 'userPassword' (EAP-TTLS with PAP in real life, simple PAP here).
Good, the search requests (conn=1044) contain the Session Tracking Control (OpenLDAP logs):
2015-06-29T10:47:05.316040+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=1 [IP=10.1.1.5 NAME=radiusd USERNAME=michael-homelan] SRCH base="cn=radiusd,ou=services,dc=stroeder,dc=local" scope=2 deref=0 filter="(uid=michael-homelan)" 2015-06-29T10:47:05.316051+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=1 [IP=10.1.1.5 NAME=radiusd USERNAME=michael-homelan] SRCH attr=userPassword radiusControlAttribute radiusRequestAttribute radiusReplyAttribute 2015-06-29T10:47:05.316244+02:00 nb2 slapd-stroeder-de[5510]: conn=1044 op=1 [IP=10.1.1.5 NAME=radiusd USERNAME=michael-homelan] SEARCH RESULT tag=101 err=0 nentries=1 text=
It seems an additional LDAP connection conn=1045 is opened:
2015-06-29T10:47:05.317153+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 fd=23 ACCEPT from IP=127.0.0.1:53074 (IP=0.0.0.0:1390) 2015-06-29T10:47:05.317219+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 op=0 BIND dn="uid=radiusd,ou=sys,dc=stroeder,dc=local" method=128 2015-06-29T10:47:05.324982+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 op=0 BIND dn="uid=radiusd,ou=sys,dc=stroeder,dc=local" mech=SIMPLE ssf=0 2015-06-29T10:47:05.325582+02:00 nb2 slapd-stroeder-de[5510]: conn=1045 op=0 RESULT tag=97 err=0 text=
But now for checking the password there is no Session Tracking Control sent along with the bind request (conn=1044, err=49 is ok because I deliberately used a wrong password):
int ldap_bind(LDAP *ld, const char *who, const char *cred, int method); int ldap_bind_s(LDAP *ld, const char *who, const char *cred, int method); int ldap_simple_bind(LDAP *ld, const char *who, const char *passwd); int ldap_simple_bind_s(LDAP *ld, const char *who, const char *passwd); int ldap_sasl_bind(LDAP *ld, const char *dn, const char *mechanism, struct berval *cred, LDAPControl *sctrls[], LDAPControl *cctrls[], int *msgidp); Because there's no libldap bind function which takes client or server controls, ug I guess we should set them on the handle and then remove them again. It's hacky but it should work. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
On 29 Jun 2015, at 04:56, Michael Ströder <michael@stroeder.com> wrote:
But now for checking the password there is no Session Tracking Control sent along with the bind request (conn=1044, err=49 is ok because I deliberately used a wrong password):
int ldap_bind(LDAP *ld, const char *who, const char *cred, int method);
int ldap_bind_s(LDAP *ld, const char *who, const char *cred, int method);
int ldap_simple_bind(LDAP *ld, const char *who, const char *passwd);
int ldap_simple_bind_s(LDAP *ld, const char *who, const char *passwd);
int ldap_sasl_bind(LDAP *ld, const char *dn, const char *mechanism, struct berval *cred, LDAPControl *sctrls[], LDAPControl *cctrls[], int *msgidp);
Because there's no libldap bind function which takes client or server controls, ug I guess we should set them on the handle and then remove them again.
Despite its misleading name you can also send simple bind requests with ldap_sasl_bind() which has arguments for controls. AFAICS that's what libldap does internally and this is was also python-ldap does. Ciao, Michael.
On 29 Jun 2015, at 09:06, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On 29 Jun 2015, at 04:56, Michael Ströder <michael@stroeder.com> wrote:
But now for checking the password there is no Session Tracking Control sent along with the bind request (conn=1044, err=49 is ok because I deliberately used a wrong password):
int ldap_bind(LDAP *ld, const char *who, const char *cred, int method);
int ldap_bind_s(LDAP *ld, const char *who, const char *cred, int method);
int ldap_simple_bind(LDAP *ld, const char *who, const char *passwd);
int ldap_simple_bind_s(LDAP *ld, const char *who, const char *passwd);
int ldap_sasl_bind(LDAP *ld, const char *dn, const char *mechanism, struct berval *cred, LDAPControl *sctrls[], LDAPControl *cctrls[], int *msgidp);
Because there's no libldap bind function which takes client or server controls, ug I guess we should set them on the handle and then remove them again.
Despite its misleading name you can also send simple bind requests with ldap_sasl_bind() which has arguments for controls. AFAICS that's what libldap does internally and this is was also python-ldap does.
Ah, yes, as done here: https://github.com/arr2036/ldapperf/blob/master/ldapperf.c#L359 It's actually in the C API draft too https://tools.ietf.org/html/draft-ietf-ldapext-ldap-c-api-05#section-11.4 Ok, pushed that to v3.1.x. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Michael Ströder