Thank you for figuring this out! I guess we need to see how upstream
wants to address the issue before we can address it in Ubuntu? Given the
root cause, it seems to me that it would only be appropriate for Ubuntu
to do what upstream does here to fix it.
** Description changed:
[Status]
-
Leif, I do agree here but this has to be a new SASL property and fixed
with Cyrus SASL. At best, one contacts the Cyrus SASL mailing list.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1015819
Leif, the commit is perfectly fine because minssf=0 is illegal and
violates the RFC. I have described this in my previous comment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1015819
Title:
Leif, the commit is perfectly fine because minssf=0 is illegal and
violates the RFC. I have described this in my previous comment.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cyrus-sasl2 in Ubuntu.
Yes I didn't mean the commit was wrong. The problem is MS-AD, but before the
commit it was possible to do LDAP SASL bind over an SSL/TLS connection to AD
if you set min and max SSF below or equal to 128 (doesn't need to be zero).
So it would be nice to have some sort of AD compatibility mode. I
Yes I didn't mean the commit was wrong. The problem is MS-AD, but before the
commit it was possible to do LDAP SASL bind over an SSL/TLS connection to AD
if you set min and max SSF below or equal to 128 (doesn't need to be zero).
So it would be nice to have some sort of AD compatibility mode. I
The workaround proposed by Johnny Westerlund on 2015-05-06
works in cyrus-sasl-2.1.23 but not in the latest version 2.1.26.
Looks like it is this commit that cause the workaround to stop working.
The workaround proposed by Johnny Westerlund on 2015-05-06
works in cyrus-sasl-2.1.23 but not in the latest version 2.1.26.
Looks like it is this commit that cause the workaround to stop working.
I highly fear that the code cannot be changed that easily because
Microsoft screwed up the RFC. The RFC
(https://tools.ietf.org/html/rfc4752#section-3.1) says:
3.1. Client Side of Authentication Protocol Exchange
The client calls GSS_Init_sec_context, passing in
input_context_handle of 0
I highly fear that the code cannot be changed that easily because
Microsoft screwed up the RFC. The RFC
(https://tools.ietf.org/html/rfc4752#section-3.1) says:
3.1. Client Side of Authentication Protocol Exchange
The client calls GSS_Init_sec_context, passing in
input_context_handle of 0
Here is a follow on the comment above:
I have changes the GSSAPI mech plugin source code:
diff --git a/plugins/gssapi.c b/plugins/gssapi.c
index 2fd1b3b..39302cd 100644
--- a/plugins/gssapi.c
+++ b/plugins/gssapi.c
@@ -1583,20 +1583,9 @@ static int gssapi_client_mech_step(void *conn_context,
Here is a follow on the comment above:
I have changes the GSSAPI mech plugin source code:
diff --git a/plugins/gssapi.c b/plugins/gssapi.c
index 2fd1b3b..39302cd 100644
--- a/plugins/gssapi.c
+++ b/plugins/gssapi.c
@@ -1583,20 +1583,9 @@ static int gssapi_client_mech_step(void *conn_context,
I can confirm that this bug is still present in the most recent versions
of OpenLDAP and SASL. Johnny Westerlund's statement is correct but the
tip isn't.
Here is the deal: https://msdn.microsoft.com/en-us/library/cc223500.aspx
Active Directory does not support GSS-API integrity/confidentiality
I can confirm that this bug is still present in the most recent versions
of OpenLDAP and SASL. Johnny Westerlund's statement is correct but the
tip isn't.
Here is the deal: https://msdn.microsoft.com/en-us/library/cc223500.aspx
Active Directory does not support GSS-API integrity/confidentiality
This has to do with Active Directory not supporting nested security or
privacy layers.
To make it work you need to set sasl_secprops minssf=0,maxssf=0 in
/etc/openldap/ldap.conf
/J
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
This has to do with Active Directory not supporting nested security or
privacy layers.
To make it work you need to set sasl_secprops minssf=0,maxssf=0 in
/etc/openldap/ldap.conf
/J
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
+ [Status]
+
+ This bug needs a developer to reproduce the problem and locate the root
+ cause.
+
+ [Workaround]
+
+ Unknown.
+
+ [Missing]
+
+ Exact steps to reproduce.
+
+ [Description]
+
Not sure if this is a problem with openldap or cyrus-sasl2 at this
** Description changed:
+ [Status]
+
+ This bug needs a developer to reproduce the problem and locate the root
+ cause.
+
+ [Workaround]
+
+ Unknown.
+
+ [Missing]
+
+ Exact steps to reproduce.
+
+ [Description]
+
Not sure if this is a problem with openldap or cyrus-sasl2 at this
Is there any update on this bug?
I have done some testing, and it seems that I can successfuly use
SSL/TLS connections to an LDAP server (both over port 636 for LDAPS and
port 389 with STARTTLS) when I use the DIGEST-MD5 SASL mechanism.
This seems to indicate that it is specifically a problem
Is there any update on this bug?
I have done some testing, and it seems that I can successfuly use
SSL/TLS connections to an LDAP server (both over port 636 for LDAPS and
port 389 with STARTTLS) when I use the DIGEST-MD5 SASL mechanism.
This seems to indicate that it is specifically a problem
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cyrus-sasl2 (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cyrus-sasl2 in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cyrus-sasl2 (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1015819
Title:
Thank you for taking the time to report this bug and helping to make
Ubuntu better.
Please could you explain the impact of this bug? Are you saying that
openldap cannot work with SSL or TLS at all, or is there a workaround?
Can openldap be used with something other than cyrus-sasl2 for SSL/TLS
I can't use GSSAPI via sasl to receive data from the ldap server if SSL
or TLS is used as I get illegal packet length errors as reported. Non
encrypted ldap is working with no issues using GSSAPI authentication.
--
You received this bug notification because you are a member of Ubuntu
Server
** Changed in: cyrus-sasl2 (Ubuntu)
Status: Incomplete = New
** Changed in: cyrus-sasl2 (Ubuntu)
Importance: Undecided = Medium
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cyrus-sasl2 in Ubuntu.
Thank you for taking the time to report this bug and helping to make
Ubuntu better.
Please could you explain the impact of this bug? Are you saying that
openldap cannot work with SSL or TLS at all, or is there a workaround?
Can openldap be used with something other than cyrus-sasl2 for SSL/TLS
I can't use GSSAPI via sasl to receive data from the ldap server if SSL
or TLS is used as I get illegal packet length errors as reported. Non
encrypted ldap is working with no issues using GSSAPI authentication.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** Changed in: cyrus-sasl2 (Ubuntu)
Status: Incomplete = New
** Changed in: cyrus-sasl2 (Ubuntu)
Importance: Undecided = Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1015819
Title:
28 matches
Mail list logo
