Bug 202872 - Allow the password modify extended op when using SASL privacy layer
Allow the password modify extended op when using SASL privacy layer
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - SASL (Show other bugs)
1.0.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
: Reopened
Depends On:
Blocks: 152373 fds103trackingbug 240316
  Show dependency treegraph
 
Reported: 2006-08-16 16:56 EDT by Nathan Kinder
Modified: 2015-12-07 11:54 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:54:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CVS Diffs (3.20 KB, patch)
2006-08-16 17:02 EDT, Nathan Kinder
no flags Details | Diff
Revised Diffs (6.96 KB, patch)
2006-08-16 19:29 EDT, Nathan Kinder
no flags Details | Diff
CVS Commit (865 bytes, patch)
2006-08-17 11:30 EDT, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Nathan Kinder 2006-08-16 16:56:59 EDT
The current behavior of the Directory Server is to only allow the password
modify extended operation when the connection is using SSL or TLS.  If you
attempt to use a connection that is not using SSL or TLS, the server returns
LDAP_CONFIDENTIALITY_REQUIRED.

We should allow the password modify extended operation if the connection is
using  a SASL security layer that has privacy.
Comment 1 Nathan Kinder 2006-08-16 17:02:50 EDT
Created attachment 134347 [details]
CVS Diffs

I added a new internal function "int ids_sasl_privacy_enabled(Connection
*conn)" that will check if a SASL security layer supporting privacy has been
netogiated for a particular connection.  This function uses the sasl_getprop()
function to check the SSF (security strength factor) to see if privacy has been
negotiated.

This function allows us to have the password modify extop code check if privacy
is enabled so it can allow the operation to be processed.  The new server
behavior is to allow the password modify extended operation if using SSL, TLS,
or a SASL privacy layer.  All other attempts will return
LDAP_CONFIDENTIALITY_REQUIRED.
Comment 2 Rich Megginson 2006-08-16 17:13:02 EDT
I think knowing if the user authenticated via sasl and if there was a privacy
layer negotiated is a generally useful thing to know i.e. we can use it in the
aci code, other preop plugin code, etc.  I think it should be slapi-plugin.h
function, or perhaps a pblock item - we already have SLAPI_CONN_IS_SSL_SESSION
in the pblock, maybe a SLAPI_CONN_HAS_SASL_PRIVACY or something like that.
Comment 3 Nathan Kinder 2006-08-16 19:29:23 EDT
Created attachment 134355 [details]
Revised Diffs

I like the idea of being able to expose if a SASL privacy layer is in use to
plugins, etc.  I think it would be most useful if we just exposed the SASL SSF
itself.  This would allow us to do things such as enhance the aci's to be able 
to specify a minimum SSF.

The attached diffs implement a new Connection parameter for the SASL SSF.  This
is exposed via the pblock as the SLAPI_CONN_SASL_SSF parameter.  We initialize
this to 0, and we update the SSF right after we install the SASL IO layer.  We
reset the SSF to 0 in the sasl_io_cleanup() function.
Comment 4 Rich Megginson 2006-08-16 19:40:27 EDT
Ok.
Comment 5 Nathan Kinder 2006-08-17 11:30:58 EDT
Created attachment 134393 [details]
CVS Commit

Checked into ldapserver (HEAD).
Comment 6 Nathan Kinder 2006-08-17 12:26:32 EDT
I have created a documentation bug to add this new pblock parameter to the
"Plug-In Programmers Guide".  The doc bug is bug 202976.
Comment 7 Nathan Kinder 2006-08-17 12:32:31 EDT
To verify the fix for this bug, perform the following tests:

- Use the ldappasswd tool to attempt to modify a user's password using simple
auth with no SSL.  The server should return a message stating "Confidentiality
required".

- Use the ldappasswd tool to attempt to modify a user's password using simple
auth with SSL.  The password change should succeed.

- Use the ldappasswd tool to attempt to modify a user's password using simple
auth with startTLS.  The password change should succeed.

- Use the ldappasswd tool to attempt to modify a user's password using SASL auth
with the CRAM-MD5 mechanism (this mechanism does not use provide privacy).  The
server should return a message stating "Confidentiality required".

- Use the ldappasswd tool to attempt to modify a user's password using SASL auth
with the CRAM-MD5 mechanism over SSL.  The password change should succeed.

- Use the ldappasswd tool to attempt to modify a user's password using SASL auth
with the CRAM-MD5 mechanism with startTLS.  The password change should succeed.

- Use the ldappasswd tool to attempt to modify a user's password using SASL auth
with the DIGEST-MD5 mechanism.  The password change should succeed.
Comment 8 Michael Gregg 2008-01-07 19:23:19 EST
- Use the ldappasswd tool to attempt to modify a user's password using simple
auth with no SSL.  The server should return a message stating "Confidentiality
required".

/usr/bin/ldappasswd -w redhat -D"cn=directory manager" -h localhost -p 1111 -s
9998 -x "uid=mgreggtest,ou=people,o=redhat" 
Result: Confidentiality required (13)
Additional info: Operation requires a secure connection.

- Use the ldappasswd tool to attempt to modify a user's password using simple
auth with SSL.  The password change should succeed.

/usr/lib/mozldap6/ldappasswd -w redhat -D "cn=directory manager" -h
brandywine.dsqa.sjc2.redhat.com -p 1112 -Z -s 9998 -a netscape -P
/etc/dirsrv/slapd-MAIN/cert8.db -K /etc/dirsrv/slapd-MAIN/key3.db
"uid=mgreggtest,ou=people,o=redhat" -a 9998
ldappasswd-bin: password successfully changed

- Use the ldappasswd tool to attempt to modify a user's password using simple
auth with startTLS.  The password change should succeed.

/usr/lib/mozldap6/ldappasswd -w redhat -D"cn=directory manager" -h localhost -p
1111 -ZZZ -s 9998 "uid=mgreggtest,ou=people,o=redhat" 

- Use the ldappasswd tool to attempt to modify a user's password using SASL auth
with the CRAM-MD5 mechanism (this mechanism does not use provide privacy).  The
server should return a message stating "Confidentiality required".

/usr/lib/mozldap6/ldappasswd -h brandywine.dsqa.sjc2.redhat.com -p 1111 -s 9998
"uid=mgreggtest,ou=people,o=redhat" -a 1234 -m CRAM-M5 -o "mech=CRAM-MD5" -o
"authid=ttest1" -w 1234

- Use the ldappasswd tool to attempt to modify a user's password using SASL auth
with the CRAM-MD5 mechanism over SSL.  The password change should succeed.

/usr/lib/mozldap6/ldappasswd -h brandywine.dsqa.sjc2.redhat.com -p 1112 -s 9998
-a 9998 -o "mech=CRAM-MD5" -o "authid=ttest1" -w 9998 -Z -P
/etc/dirsrv/slapd-MAIN/cert8.db -K /etc/dirsrv/slapd-MAIN/key3.db
"uid=ttest1,ou=testpeople,o=sasl.com" 
ldappasswd-bin: password successfully changed

- Use the ldappasswd tool to attempt to modify a user's password using SASL auth
with the CRAM-MD5 mechanism with startTLS.  The password change should succeed.

/usr/lib/mozldap6/ldappasswd -h brandywine.dsqa.sjc2.redhat.com -p 1111 -s 9998
"uid=ttest1,ou=testpeople,o=sasl.com" -a 1234 -m CRAM-M5 -o "mech=CRAM-MD5" -o
"authid=ttest1" -w 1234 -ZZ
ldappasswd-bin: password successfully changed



Verified aginst:
1199305764 idm-console-framework-1.1.0-7.el4idm Wed Jan 02 2008 
1199305765 redhat-ds-console-8.0.0-9.el4dsrv Wed Jan 02 2008 
1199305766 redhat-admin-console-8.0.0-9.el4dsrv Wed Jan 02 2008 
1199305768 redhat-idm-console-1.0.0-21.el4idm Wed Jan 02 2008 
1199390834 net-snmp-libs-5.1.2-11.el4_6.11.1 Thu Jan 03 2008 
1199390890 net-snmp-5.1.2-11.el4_6.11.1 Thu Jan 03 2008 
1199391027 db4-4.2.52-7.3.el4 Thu Jan 03 2008 
1199391030 db4-utils-4.2.52-7.3.el4 Thu Jan 03 2008 
1199391031 db4-tcl-4.2.52-7.3.el4 Thu Jan 03 2008 
1199391034 db4-java-4.2.52-7.3.el4 Thu Jan 03 2008 
1199391044 db4-devel-4.2.52-7.3.el4 Thu Jan 03 2008 
1199391134 cyrus-sasl-2.1.19-14 Thu Jan 03 2008 
1199391137 cyrus-sasl-md5-2.1.19-14 Thu Jan 03 2008 
1199391138 cyrus-sasl-gssapi-2.1.19-14 Thu Jan 03 2008 
1199391138 cyrus-sasl-plain-2.1.19-14 Thu Jan 03 2008 
1199391138 cyrus-sasl-sql-2.1.19-14 Thu Jan 03 2008 
1199391139 cyrus-sasl-ntlm-2.1.19-14 Thu Jan 03 2008 
1199391140 cyrus-sasl-devel-2.1.19-14 Thu Jan 03 2008 

Note You need to log in before you can comment on or make changes to this bug.