Hello,
please see attached patch.
To test connect to AD using ldap provider (for both id and auth). Lock account of AD user by entering invalid password repeatedly. In pam section of sssd.conf set pam_account_locked_message option. After failing to su as locked user you should see message containing this information.
Thanks!
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
Hello,
please see attached patch.
To test connect to AD using ldap provider (for both id and auth). Lock account of AD user by entering invalid password repeatedly. In pam section of sssd.conf set pam_account_locked_message option. After failing to su as locked user you should see message containing this information.
Thanks!
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Tue, 2 Feb 2016 14:35:15 -0500 Subject: [PATCH] PAM: Notify user of denial due to AD account lockout
Resolves: https://fedorahosted.org/sssd/ticket/2839
index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& strstr(errmsg, "data 775,") != NULL) {
~~~~~~~~~~~~~~ I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
On 02/05/2016 11:01 AM, Jakub Hrozek wrote:
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
...
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
Done.
From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Tue, 2 Feb 2016 14:35:15 -0500 Subject: [PATCH] PAM: Notify user of denial due to AD account lockout
Resolves: https://fedorahosted.org/sssd/ticket/2839
index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& strstr(errmsg, "data 775,") != NULL) {
~~~~~~~~~~~~~~
I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Sure.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
I pinged Dan about that.
Please see updated patch set, thanks!
On (05/02/16 13:55), Pavel Reichl wrote:
On 02/05/2016 11:01 AM, Jakub Hrozek wrote:
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
...
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
Done.
From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Tue, 2 Feb 2016 14:35:15 -0500 Subject: [PATCH] PAM: Notify user of denial due to AD account lockout
Resolves: https://fedorahosted.org/sssd/ticket/2839
index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& strstr(errmsg, "data 775,") != NULL) {
~~~~~~~~~~~~~~
I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Sure.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
I pinged Dan about that.
Please see updated patch set, thanks!
From 4adb25b045be46dc0a178748e2b0aeb5ea09ed1d Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Resolves: https://fedorahosted.org/sssd/ticket/2839
src/providers/data_provider.h | 2 ++ src/providers/ldap/ldap_auth.c | 4 ++++ src/providers/ldap/sdap_async_connection.c | 3 +++ 3 files changed, 9 insertions(+)
diff --git a/src/providers/data_provider.h b/src/providers/data_provider.h index 39051b90c3aad96f62dcbb86a20bcfd8c954879b..7332b677d19f70f4736e4d0b68d55cdd3c67a4af 100644 --- a/src/providers/data_provider.h +++ b/src/providers/data_provider.h @@ -182,6 +182,8 @@ struct pam_data { bool offline_auth; bool last_auth_saved; int priv;
- int account_locked;
#ifdef USE_KEYRING key_serial_t key_serial; #endif diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c index c94ba15bb17aa1641eb36781cc59ce158d48ca66..8d6a37b2ceb3347cb8092858889d07e5615e5c77 100644 --- a/src/providers/ldap/ldap_auth.c +++ b/src/providers/ldap/ldap_auth.c @@ -1302,6 +1302,10 @@ static void sdap_pam_auth_done(struct tevent_req *req) case ERR_PASSWORD_EXPIRED: state->pd->pam_status = PAM_NEW_AUTHTOK_REQD; break;
- case ERR_ACCOUNT_LOCKED:
state->pd->account_locked = true;
state->pd->pam_status = PAM_PERM_DENIED;
default: state->pd->pam_status = PAM_SYSTEM_ERR; dp_err = DP_ERR_FATAL;break;
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..c1735513ff6dcc755daf06cb97da546eaded7eb9 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& errmsg != NULL && strstr(errmsg, "data 775,") != NULL) {
This searching of string seems to be vague to me. Will it work with any version of AD?
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
LS
On Fri, Feb 05, 2016 at 02:54:53PM +0100, Lukas Slebodnik wrote:
On (05/02/16 13:55), Pavel Reichl wrote:
On 02/05/2016 11:01 AM, Jakub Hrozek wrote:
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
...
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
Done.
From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Tue, 2 Feb 2016 14:35:15 -0500 Subject: [PATCH] PAM: Notify user of denial due to AD account lockout
Resolves: https://fedorahosted.org/sssd/ticket/2839
index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& strstr(errmsg, "data 775,") != NULL) {
~~~~~~~~~~~~~~
I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Sure.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
I pinged Dan about that.
Please see updated patch set, thanks!
From 4adb25b045be46dc0a178748e2b0aeb5ea09ed1d Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Resolves: https://fedorahosted.org/sssd/ticket/2839
src/providers/data_provider.h | 2 ++ src/providers/ldap/ldap_auth.c | 4 ++++ src/providers/ldap/sdap_async_connection.c | 3 +++ 3 files changed, 9 insertions(+)
diff --git a/src/providers/data_provider.h b/src/providers/data_provider.h index 39051b90c3aad96f62dcbb86a20bcfd8c954879b..7332b677d19f70f4736e4d0b68d55cdd3c67a4af 100644 --- a/src/providers/data_provider.h +++ b/src/providers/data_provider.h @@ -182,6 +182,8 @@ struct pam_data { bool offline_auth; bool last_auth_saved; int priv;
- int account_locked;
#ifdef USE_KEYRING key_serial_t key_serial; #endif diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c index c94ba15bb17aa1641eb36781cc59ce158d48ca66..8d6a37b2ceb3347cb8092858889d07e5615e5c77 100644 --- a/src/providers/ldap/ldap_auth.c +++ b/src/providers/ldap/ldap_auth.c @@ -1302,6 +1302,10 @@ static void sdap_pam_auth_done(struct tevent_req *req) case ERR_PASSWORD_EXPIRED: state->pd->pam_status = PAM_NEW_AUTHTOK_REQD; break;
- case ERR_ACCOUNT_LOCKED:
state->pd->account_locked = true;
state->pd->pam_status = PAM_PERM_DENIED;
default: state->pd->pam_status = PAM_SYSTEM_ERR; dp_err = DP_ERR_FATAL;break;
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..c1735513ff6dcc755daf06cb97da546eaded7eb9 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& errmsg != NULL && strstr(errmsg, "data 775,") != NULL) {
This searching of string seems to be vague to me. Will it work with any version of AD?
If not, we just don't display a message..I mean, this is already an error path.
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
On (05/02/16 15:10), Jakub Hrozek wrote:
On Fri, Feb 05, 2016 at 02:54:53PM +0100, Lukas Slebodnik wrote:
On (05/02/16 13:55), Pavel Reichl wrote:
On 02/05/2016 11:01 AM, Jakub Hrozek wrote:
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
...
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
Done.
From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Tue, 2 Feb 2016 14:35:15 -0500 Subject: [PATCH] PAM: Notify user of denial due to AD account lockout
Resolves: https://fedorahosted.org/sssd/ticket/2839
index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& strstr(errmsg, "data 775,") != NULL) {
~~~~~~~~~~~~~~
I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Sure.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
I pinged Dan about that.
Please see updated patch set, thanks!
From 4adb25b045be46dc0a178748e2b0aeb5ea09ed1d Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Resolves: https://fedorahosted.org/sssd/ticket/2839
src/providers/data_provider.h | 2 ++ src/providers/ldap/ldap_auth.c | 4 ++++ src/providers/ldap/sdap_async_connection.c | 3 +++ 3 files changed, 9 insertions(+)
diff --git a/src/providers/data_provider.h b/src/providers/data_provider.h index 39051b90c3aad96f62dcbb86a20bcfd8c954879b..7332b677d19f70f4736e4d0b68d55cdd3c67a4af 100644 --- a/src/providers/data_provider.h +++ b/src/providers/data_provider.h @@ -182,6 +182,8 @@ struct pam_data { bool offline_auth; bool last_auth_saved; int priv;
- int account_locked;
#ifdef USE_KEYRING key_serial_t key_serial; #endif diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c index c94ba15bb17aa1641eb36781cc59ce158d48ca66..8d6a37b2ceb3347cb8092858889d07e5615e5c77 100644 --- a/src/providers/ldap/ldap_auth.c +++ b/src/providers/ldap/ldap_auth.c @@ -1302,6 +1302,10 @@ static void sdap_pam_auth_done(struct tevent_req *req) case ERR_PASSWORD_EXPIRED: state->pd->pam_status = PAM_NEW_AUTHTOK_REQD; break;
- case ERR_ACCOUNT_LOCKED:
state->pd->account_locked = true;
state->pd->pam_status = PAM_PERM_DENIED;
default: state->pd->pam_status = PAM_SYSTEM_ERR; dp_err = DP_ERR_FATAL;break;
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..c1735513ff6dcc755daf06cb97da546eaded7eb9 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& errmsg != NULL && strstr(errmsg, "data 775,") != NULL) {
This searching of string seems to be vague to me. Will it work with any version of AD?
If not, we just don't display a message..I mean, this is already an error path.
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
LS
On Fri, Feb 05, 2016 at 03:16:18PM +0100, Lukas Slebodnik wrote:
On (05/02/16 15:10), Jakub Hrozek wrote:
On Fri, Feb 05, 2016 at 02:54:53PM +0100, Lukas Slebodnik wrote:
On (05/02/16 13:55), Pavel Reichl wrote:
On 02/05/2016 11:01 AM, Jakub Hrozek wrote:
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
...
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
Done.
From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Tue, 2 Feb 2016 14:35:15 -0500 Subject: [PATCH] PAM: Notify user of denial due to AD account lockout
Resolves: https://fedorahosted.org/sssd/ticket/2839
index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& strstr(errmsg, "data 775,") != NULL) {
~~~~~~~~~~~~~~
I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Sure.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
I pinged Dan about that.
Please see updated patch set, thanks!
From 4adb25b045be46dc0a178748e2b0aeb5ea09ed1d Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Resolves: https://fedorahosted.org/sssd/ticket/2839
src/providers/data_provider.h | 2 ++ src/providers/ldap/ldap_auth.c | 4 ++++ src/providers/ldap/sdap_async_connection.c | 3 +++ 3 files changed, 9 insertions(+)
diff --git a/src/providers/data_provider.h b/src/providers/data_provider.h index 39051b90c3aad96f62dcbb86a20bcfd8c954879b..7332b677d19f70f4736e4d0b68d55cdd3c67a4af 100644 --- a/src/providers/data_provider.h +++ b/src/providers/data_provider.h @@ -182,6 +182,8 @@ struct pam_data { bool offline_auth; bool last_auth_saved; int priv;
- int account_locked;
#ifdef USE_KEYRING key_serial_t key_serial; #endif diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c index c94ba15bb17aa1641eb36781cc59ce158d48ca66..8d6a37b2ceb3347cb8092858889d07e5615e5c77 100644 --- a/src/providers/ldap/ldap_auth.c +++ b/src/providers/ldap/ldap_auth.c @@ -1302,6 +1302,10 @@ static void sdap_pam_auth_done(struct tevent_req *req) case ERR_PASSWORD_EXPIRED: state->pd->pam_status = PAM_NEW_AUTHTOK_REQD; break;
- case ERR_ACCOUNT_LOCKED:
state->pd->account_locked = true;
state->pd->pam_status = PAM_PERM_DENIED;
default: state->pd->pam_status = PAM_SYSTEM_ERR; dp_err = DP_ERR_FATAL;break;
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..c1735513ff6dcc755daf06cb97da546eaded7eb9 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& errmsg != NULL && strstr(errmsg, "data 775,") != NULL) {
This searching of string seems to be vague to me. Will it work with any version of AD?
If not, we just don't display a message..I mean, this is already an error path.
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
I'm not sure we can find official documentation, at least I didn't find one. We can test with multiple AD versions, but that's about it.
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
Yeah, me too, please find one. I couldn't.
https://technet.microsoft.com/en-us/library/cc526636.aspx https://support.microsoft.com/en-us/kb/218185
?
On 02/05/2016 09:31 AM, Jakub Hrozek wrote:
On Fri, Feb 05, 2016 at 03:16:18PM +0100, Lukas Slebodnik wrote:
On (05/02/16 15:10), Jakub Hrozek wrote:
On Fri, Feb 05, 2016 at 02:54:53PM +0100, Lukas Slebodnik wrote:
On (05/02/16 13:55), Pavel Reichl wrote:
On 02/05/2016 11:01 AM, Jakub Hrozek wrote:
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
...
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
Done.
> From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 > From: Pavel Reichl preichl@redhat.com > Date: Tue, 2 Feb 2016 14:35:15 -0500 > Subject: [PATCH] PAM: Notify user of denial due to AD account lockout > > Resolves: > https://fedorahosted.org/sssd/ticket/2839 > --- > index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 > --- a/src/providers/ldap/sdap_async_connection.c > +++ b/src/providers/ldap/sdap_async_connection.c > @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op, > > if (result == LDAP_SUCCESS) { > ret = EOK; > + } else if (result == LDAP_INVALID_CREDENTIALS > + && strstr(errmsg, "data 775,") != NULL) { ~~~~~~~~~~~~~~ I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Sure.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
I pinged Dan about that.
Please see updated patch set, thanks! From 4adb25b045be46dc0a178748e2b0aeb5ea09ed1d Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Resolves: https://fedorahosted.org/sssd/ticket/2839
src/providers/data_provider.h | 2 ++ src/providers/ldap/ldap_auth.c | 4 ++++ src/providers/ldap/sdap_async_connection.c | 3 +++ 3 files changed, 9 insertions(+)
diff --git a/src/providers/data_provider.h b/src/providers/data_provider.h index 39051b90c3aad96f62dcbb86a20bcfd8c954879b..7332b677d19f70f4736e4d0b68d55cdd3c67a4af 100644 --- a/src/providers/data_provider.h +++ b/src/providers/data_provider.h @@ -182,6 +182,8 @@ struct pam_data { bool offline_auth; bool last_auth_saved; int priv;
- int account_locked;
#ifdef USE_KEYRING key_serial_t key_serial; #endif diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c index c94ba15bb17aa1641eb36781cc59ce158d48ca66..8d6a37b2ceb3347cb8092858889d07e5615e5c77 100644 --- a/src/providers/ldap/ldap_auth.c +++ b/src/providers/ldap/ldap_auth.c @@ -1302,6 +1302,10 @@ static void sdap_pam_auth_done(struct tevent_req *req) case ERR_PASSWORD_EXPIRED: state->pd->pam_status = PAM_NEW_AUTHTOK_REQD; break;
- case ERR_ACCOUNT_LOCKED:
state->pd->account_locked = true;
state->pd->pam_status = PAM_PERM_DENIED;
default: state->pd->pam_status = PAM_SYSTEM_ERR; dp_err = DP_ERR_FATAL;break;
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..c1735513ff6dcc755daf06cb97da546eaded7eb9 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& errmsg != NULL && strstr(errmsg, "data 775,") != NULL) {
This searching of string seems to be vague to me. Will it work with any version of AD?
If not, we just don't display a message..I mean, this is already an error path.
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
I'm not sure we can find official documentation, at least I didn't find one. We can test with multiple AD versions, but that's about it.
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
Yeah, me too, please find one. I couldn't. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 02/05/2016 03:42 PM, Dan Lavu wrote:
https://technet.microsoft.com/en-us/library/cc526636.aspx https://support.microsoft.com/en-us/kb/218185
?
Dan, I might have missed it but I don't see there any mention of AD returning 'data 775' in case that account is locked (which is a sub case of error invalid credentials).
Pavel,
I found the wording to be strange, this is shorter and more concise description of the parameter. I also took the liberty of editing the description of 'pam_account_expired_message' as well. I don't think the comment about ssh keys is necessary, since it applies to all pam auth phase not just keys.
Dan
On 02/05/2016 09:16 AM, Lukas Slebodnik wrote:
On (05/02/16 15:10), Jakub Hrozek wrote:
On Fri, Feb 05, 2016 at 02:54:53PM +0100, Lukas Slebodnik wrote:
On (05/02/16 13:55), Pavel Reichl wrote:
On 02/05/2016 11:01 AM, Jakub Hrozek wrote:
On Tue, Feb 02, 2016 at 08:48:43PM +0100, Pavel Reichl wrote:
...
I would prefer to split this patch into two, one that patches the LDAP code to return ERR_ACCOUNT_LOCKED and one that passes on and displays the message.
Done.
From 511ef599902827d76193a1e634ace193df15dead Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Tue, 2 Feb 2016 14:35:15 -0500 Subject: [PATCH] PAM: Notify user of denial due to AD account lockout
Resolves: https://fedorahosted.org/sssd/ticket/2839
index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..763c5ed050bd482d334ad617349938dfc89f79da 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& strstr(errmsg, "data 775,") != NULL) {
~~~~~~~~~~~~~~
I don't think this is safe, strstr() doesn't handle NULL input well. Please add a check for "&& errmgs != NULL" before calling strstr.
Sure.
Otherwise the patch looks good, we just need to also ask some Native speaker for manpage comments..
I pinged Dan about that.
Please see updated patch set, thanks! From 4adb25b045be46dc0a178748e2b0aeb5ea09ed1d Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Resolves: https://fedorahosted.org/sssd/ticket/2839
src/providers/data_provider.h | 2 ++ src/providers/ldap/ldap_auth.c | 4 ++++ src/providers/ldap/sdap_async_connection.c | 3 +++ 3 files changed, 9 insertions(+)
diff --git a/src/providers/data_provider.h b/src/providers/data_provider.h index 39051b90c3aad96f62dcbb86a20bcfd8c954879b..7332b677d19f70f4736e4d0b68d55cdd3c67a4af 100644 --- a/src/providers/data_provider.h +++ b/src/providers/data_provider.h @@ -182,6 +182,8 @@ struct pam_data { bool offline_auth; bool last_auth_saved; int priv;
- int account_locked;
#ifdef USE_KEYRING key_serial_t key_serial; #endif diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c index c94ba15bb17aa1641eb36781cc59ce158d48ca66..8d6a37b2ceb3347cb8092858889d07e5615e5c77 100644 --- a/src/providers/ldap/ldap_auth.c +++ b/src/providers/ldap/ldap_auth.c @@ -1302,6 +1302,10 @@ static void sdap_pam_auth_done(struct tevent_req *req) case ERR_PASSWORD_EXPIRED: state->pd->pam_status = PAM_NEW_AUTHTOK_REQD; break;
- case ERR_ACCOUNT_LOCKED:
state->pd->account_locked = true;
state->pd->pam_status = PAM_PERM_DENIED;
default: state->pd->pam_status = PAM_SYSTEM_ERR; dp_err = DP_ERR_FATAL;break;
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c index 2d9b1184f5d30b9df7f1d3e4b980a7e0107c6830..c1735513ff6dcc755daf06cb97da546eaded7eb9 100644 --- a/src/providers/ldap/sdap_async_connection.c +++ b/src/providers/ldap/sdap_async_connection.c @@ -754,6 +754,9 @@ static void simple_bind_done(struct sdap_op *op,
if (result == LDAP_SUCCESS) { ret = EOK;
- } else if (result == LDAP_INVALID_CREDENTIALS
&& errmsg != NULL && strstr(errmsg, "data 775,") != NULL) {
This searching of string seems to be vague to me. Will it work with any version of AD?
If not, we just don't display a message..I mean, this is already an error path.
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 02/05/2016 03:37 PM, Dan Lavu wrote:
Pavel,
I found the wording to be strange, this is shorter and more concise description of the parameter. I also took the liberty of editing the description of 'pam_account_expired_message' as well. I don't think the comment about ssh keys is necessary, since it applies to all pam auth phase not just keys.
Dan
Thanks Dan, ssh keys were used because for default value of pam_verbosity, for other services then ssh would nothing be outputted (as a security measure).
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
We don't have any and it's possible it's not publicly documented.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
We don't have any and it's possible it's not publicly documented.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On (08/02/16 10:48), Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
If you have an access to such machines it would be good to test. I do not have licences :-(.
We *might* check with samba AD. It needn't work therefore it should not be a blocker for this patch. But we had some samba AD specific crashed in past which would be good to avoid.
Or just check samba source code whether it has such string in code.
LS
On (08/02/16 12:12), Lukas Slebodnik wrote:
On (08/02/16 10:48), Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
If you have an access to such machines it would be good to test. I do not have licences :-(.
We *might* check with samba AD. It needn't work therefore it should not be a blocker for this patch. But we had some samba AD specific crashed in past which would be good to avoid.
Or just check samba source code whether it has such string in code.
I checked the samba source code and it looks like there can be zeros before 775
libcli/util/werror.h:#define WERR_ACCOUNT_LOCKED_OUT W_ERROR(0x00000775) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg)
LS
On Mon, Feb 08, 2016 at 04:18:56PM +0100, Lukas Slebodnik wrote:
On (08/02/16 12:12), Lukas Slebodnik wrote:
On (08/02/16 10:48), Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
If you have an access to such machines it would be good to test. I do not have licences :-(.
We *might* check with samba AD. It needn't work therefore it should not be a blocker for this patch. But we had some samba AD specific crashed in past which would be good to avoid.
Or just check samba source code whether it has such string in code.
I checked the samba source code and it looks like there can be zeros before 775
libcli/util/werror.h:#define WERR_ACCOUNT_LOCKED_OUT W_ERROR(0x00000775) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg)
Those are checks which tests some samba behaviour:
source4/dsdb/samdb/ldb_modules/password_hash.c: ... if (NT_STATUS_EQUAL(status, NT_STATUS_ACCOUNT_LOCKED_OUT)) { ldb_asprintf_errstring(ldb, "%08X: check_password: " "Password change not permitted, account locked out!", W_ERROR_V(WERR_ACCOUNT_LOCKED_OUT)); return LDB_ERR_CONSTRAINT_VIOLATION; } ...
which as far as I can see are not related to error messages during bind.
I agree that we should test how Samba behaves here and which error messages is send while trying to bind as a locked out user. But I think it would be sufficient to open a ticket to test it and if Samba behaves differently we might want to discuss with Samba upstream if this is expected.
bye, Sumit
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On (08/02/16 17:18), Sumit Bose wrote:
On Mon, Feb 08, 2016 at 04:18:56PM +0100, Lukas Slebodnik wrote:
On (08/02/16 12:12), Lukas Slebodnik wrote:
On (08/02/16 10:48), Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
> The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
If you have an access to such machines it would be good to test. I do not have licences :-(.
We *might* check with samba AD. It needn't work therefore it should not be a blocker for this patch. But we had some samba AD specific crashed in past which would be good to avoid.
Or just check samba source code whether it has such string in code.
I checked the samba source code and it looks like there can be zeros before 775
libcli/util/werror.h:#define WERR_ACCOUNT_LOCKED_OUT W_ERROR(0x00000775) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('00000775' in msg) source4/dsdb/tests/python/password_lockout.py: self.assertTrue('0000775' in msg)
Those are checks which tests some samba behaviour:
source4/dsdb/samdb/ldb_modules/password_hash.c: ... if (NT_STATUS_EQUAL(status, NT_STATUS_ACCOUNT_LOCKED_OUT)) { ldb_asprintf_errstring(ldb, "%08X: check_password: " "Password change not permitted, account locked out!", W_ERROR_V(WERR_ACCOUNT_LOCKED_OUT)); return LDB_ERR_CONSTRAINT_VIOLATION; } ...
which as far as I can see are not related to error messages during bind.
Thank you for deeper look into the code. I only did quick grep of samba master and saw two "keywords". password_lockout and 775.
I agree that we should test how Samba behaves here and which error messages is send while trying to bind as a locked out user. But I think it would be sufficient to open a ticket to test it and if Samba behaves differently we might want to discuss with Samba upstream if this is expected.
Agree. I wrote in my previous mail that samab shoudl not be a blocker. But we should not crash with samba in any case.
LS
On 02/09/2016 08:12 AM, Lukas Slebodnik wrote:
On (08/02/16 17:18), Sumit Bose wrote:
[snip]
Agree. I wrote in my previous mail that samab shoudl not be a blocker. But we should not crash with samba in any case.
Why should the patch cause crash? I don't see it. Could you be more specific please?
If format of message would be different than access would be denied...no crash.
On 02/08/2016 10:48 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
OK, done.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
I updated the relevant BZ.
On (08/02/16 13:56), Pavel Reichl wrote:
On 02/08/2016 10:48 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
OK, done.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
I updated the relevant BZ.
From 5a4ca73e16e4eec023108387cd8c572c34496e9b Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Tested against Windows Server 2012
Thank you very much for testing. I really appreciate it. It would be enought to test with one kind of AD if we planned to push the patch only to master branch.
However there is a plan to push it also to stable branch. It would be good to test with more versions. We kind of suport few version of AD. /* Values from * http://msdn.microsoft.com/en-us/library/cc223272%28v=prot.13%29.aspx */ enum dc_functional_level { DS_BEHAVIOR_WIN2000 = 0, DS_BEHAVIOR_WIN2003 = 2, DS_BEHAVIOR_WIN2008 = 3, DS_BEHAVIOR_WIN2008R2 = 4, DS_BEHAVIOR_WIN2012 = 5, DS_BEHAVIOR_WIN2012R2 = 6 };
If we are not bale to find the behaviour in the MSDN documentation then we should do upstream first testing and do not rely on later testing of patches in stable branch.
I know that you have AD licences it should not be a problem for you. BTW Petr Spacek has tech preview of AD 2016 IIRC. We might test it as well.
LS
On Tue, Feb 09, 2016 at 08:09:33AM +0100, Lukas Slebodnik wrote:
On (08/02/16 13:56), Pavel Reichl wrote:
On 02/08/2016 10:48 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
OK, done.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
I updated the relevant BZ.
From 5a4ca73e16e4eec023108387cd8c572c34496e9b Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Tested against Windows Server 2012
Thank you very much for testing. I really appreciate it. It would be enought to test with one kind of AD if we planned to push the patch only to master branch.
However there is a plan to push it also to stable branch. It would be good to test with more versions. We kind of suport few version of AD. /* Values from
*/ enum dc_functional_level { DS_BEHAVIOR_WIN2000 = 0, DS_BEHAVIOR_WIN2003 = 2, DS_BEHAVIOR_WIN2008 = 3, DS_BEHAVIOR_WIN2008R2 = 4, DS_BEHAVIOR_WIN2012 = 5, DS_BEHAVIOR_WIN2012R2 = 6 };
If we are not bale to find the behaviour in the MSDN documentation then we should do upstream first testing and do not rely on later testing of patches in stable branch.
I don't think we should put any effort into testing server versions that are not supported by Microsoft anymore. That would be like testing IPA features with IPA 2.x..
On (09/02/16 08:15), Jakub Hrozek wrote:
On Tue, Feb 09, 2016 at 08:09:33AM +0100, Lukas Slebodnik wrote:
On (08/02/16 13:56), Pavel Reichl wrote:
On 02/08/2016 10:48 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
> The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
OK, done.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
I updated the relevant BZ.
From 5a4ca73e16e4eec023108387cd8c572c34496e9b Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Tested against Windows Server 2012
Thank you very much for testing. I really appreciate it. It would be enought to test with one kind of AD if we planned to push the patch only to master branch.
However there is a plan to push it also to stable branch. It would be good to test with more versions. We kind of suport few version of AD. /* Values from
*/ enum dc_functional_level { DS_BEHAVIOR_WIN2000 = 0, DS_BEHAVIOR_WIN2003 = 2, DS_BEHAVIOR_WIN2008 = 3, DS_BEHAVIOR_WIN2008R2 = 4, DS_BEHAVIOR_WIN2012 = 5, DS_BEHAVIOR_WIN2012R2 = 6 };
If we are not bale to find the behaviour in the MSDN documentation then we should do upstream first testing and do not rely on later testing of patches in stable branch.
I don't think we should put any effort into testing server versions that are not supported by Microsoft anymore. That would be like testing IPA features with IPA 2.x..
I didn't ask to test all version. I asked to test *MORE* versions. e.g. >= 2008
LS
On Tue, Feb 09, 2016 at 08:20:38AM +0100, Lukas Slebodnik wrote:
On (09/02/16 08:15), Jakub Hrozek wrote:
On Tue, Feb 09, 2016 at 08:09:33AM +0100, Lukas Slebodnik wrote:
On (08/02/16 13:56), Pavel Reichl wrote:
On 02/08/2016 10:48 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote: >> >The ticket is about "SSSD should be about to display message to the user when >the account in Active Directory is 'locked out'" > >If the string is not standardized among AD versions >than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
OK, done.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
I updated the relevant BZ.
From 5a4ca73e16e4eec023108387cd8c572c34496e9b Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Tested against Windows Server 2012
Thank you very much for testing. I really appreciate it. It would be enought to test with one kind of AD if we planned to push the patch only to master branch.
However there is a plan to push it also to stable branch. It would be good to test with more versions. We kind of suport few version of AD. /* Values from
*/ enum dc_functional_level { DS_BEHAVIOR_WIN2000 = 0, DS_BEHAVIOR_WIN2003 = 2, DS_BEHAVIOR_WIN2008 = 3, DS_BEHAVIOR_WIN2008R2 = 4, DS_BEHAVIOR_WIN2012 = 5, DS_BEHAVIOR_WIN2012R2 = 6 };
If we are not bale to find the behaviour in the MSDN documentation then we should do upstream first testing and do not rely on later testing of patches in stable branch.
I don't think we should put any effort into testing server versions that are not supported by Microsoft anymore. That would be like testing IPA features with IPA 2.x..
I didn't ask to test all version. I asked to test *MORE* versions. e.g. >= 2008
Yes, we should test those.
On Tue, Feb 09, 2016 at 08:20:38AM +0100, Lukas Slebodnik wrote:
On (09/02/16 08:15), Jakub Hrozek wrote:
On Tue, Feb 09, 2016 at 08:09:33AM +0100, Lukas Slebodnik wrote:
On (08/02/16 13:56), Pavel Reichl wrote:
On 02/08/2016 10:48 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote: >> >The ticket is about "SSSD should be about to display message to the user when >the account in Active Directory is 'locked out'" > >If the string is not standardized among AD versions >than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
OK, done.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
I updated the relevant BZ.
From 5a4ca73e16e4eec023108387cd8c572c34496e9b Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
Add code to distinquish state when account is locked in Active Directory server.
Tested against Windows Server 2012
Thank you very much for testing. I really appreciate it. It would be enought to test with one kind of AD if we planned to push the patch only to master branch.
However there is a plan to push it also to stable branch. It would be good to test with more versions. We kind of suport few version of AD. /* Values from
*/ enum dc_functional_level { DS_BEHAVIOR_WIN2000 = 0, DS_BEHAVIOR_WIN2003 = 2, DS_BEHAVIOR_WIN2008 = 3, DS_BEHAVIOR_WIN2008R2 = 4, DS_BEHAVIOR_WIN2012 = 5, DS_BEHAVIOR_WIN2012R2 = 6 };
If we are not bale to find the behaviour in the MSDN documentation then we should do upstream first testing and do not rely on later testing of patches in stable branch.
I don't think we should put any effort into testing server versions that are not supported by Microsoft anymore. That would be like testing IPA features with IPA 2.x..
I didn't ask to test all version. I asked to test *MORE* versions. e.g. >= 2008
I can confirm that the patches are working with WIN2008R2.
bye, Sumit
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote:
On 02/08/2016 10:48 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
It would be nice to mention what we tested with in the commit message.
OK, done.
Can we ask our QA to test on all AD version they can lay their hands on?
Yes, I think we can test 2012 and 2008. Probably not worth testing 2003 anymore.
I updated the relevant BZ.
From 5a4ca73e16e4eec023108387cd8c572c34496e9b Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:27:38 -0500 Subject: [PATCH 1/2] SDAP: Add return code ERR_ACCOUNT_LOCKED
ACK. This made pam_sss return "6 (Permission denied)".
From 637766eb543a54d4a96ae5c9692566a02522a742 Mon Sep 17 00:00:00 2001 From: Pavel Reichl preichl@redhat.com Date: Fri, 5 Feb 2016 07:31:45 -0500 Subject: [PATCH 2/2] PAM: Pass account lockout status and display message
Tested against Windows Server 2012.
Yes, me too, I don't have 2008 around.
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, please call help desk. </listitem> </varlistentry> <varlistentry>
<term>pam_account_locked_message (string)</term>
<listitem>
<para>
If user is authenticating and
Please ask someone for an English review (I know Dan started, but I didn't see a fixed version yet). At the very least, this should read "a user".
account is locked then by default
'Permission denied' is output. This output will
be changed to content of this variable if it is
set.
</para>
<para>
example:
<programlisting>
+pam_account_locked_message = Account locked, please call help desk.
</programlisting>
</para>
<para>
Default: none
</para>
</listitem>
</varlistentry>
<varlistentry> <term>p11_child_timeout (integer)</term> <listitem> <para>
The rest of the patch looks good to me and seems to work as advertized.
On 02/09/2016 08:09 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote:
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, please call help desk. </listitem> </varlistentry> <varlistentry>
<term>pam_account_locked_message (string)</term>
<listitem>
<para>
If user is authenticating and
Please ask someone for an English review (I know Dan started, but I didn't see a fixed version yet). At the very least, this should read "a user".
I attached Dan's patch. I took the liberty of adding note regarding pam verbosity. Hope it's fine by Dan.
account is locked then by default
'Permission denied' is output. This output will
be changed to content of this variable if it is
set.
</para>
<para>
example:
<programlisting>
+pam_account_locked_message = Account locked, please call help desk.
</programlisting>
</para>
<para>
Default: none
</para>
</listitem>
</varlistentry>
<varlistentry> <term>p11_child_timeout (integer)</term> <listitem> <para>
The rest of the patch looks good to me and seems to work as advertized.
Thanks.
ack, looks good!
On 2/9/16 10:25 AM, Pavel Reichl wrote:
On 02/09/2016 08:09 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote:
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, please call help desk. </listitem> </varlistentry> <varlistentry>
<term>pam_account_locked_message (string)</term>
<listitem>
<para>
If user is authenticating and
Please ask someone for an English review (I know Dan started, but I didn't see a fixed version yet). At the very least, this should read "a user".
I attached Dan's patch. I took the liberty of adding note regarding pam verbosity. Hope it's fine by Dan.
account is locked then by default
'Permission denied' is output. This
output will
be changed to content of this variable
if it is
set.
</para>
<para>
example:
<programlisting>
+pam_account_locked_message = Account locked, please call help desk.
</programlisting>
</para>
<para>
Default: none
</para>
</listitem>
</varlistentry>
<varlistentry> <term>p11_child_timeout (integer)</term> <listitem> <para>
The rest of the patch looks good to me and seems to work as advertized.
Thanks.
On 02/09/2016 04:25 PM, Pavel Reichl wrote:
On 02/09/2016 08:09 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote:
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, please call help desk. </listitem> </varlistentry> <varlistentry>
<term>pam_account_locked_message (string)</term>
<listitem>
<para>
If user is authenticating and
Please ask someone for an English review (I know Dan started, but I didn't see a fixed version yet). At the very least, this should read "a user".
I attached Dan's patch. I took the liberty of adding note regarding pam verbosity. Hope it's fine by Dan.
account is locked then by default
'Permission denied' is output. This output will
be changed to content of this variable if it is
set.
</para>
<para>
example:
<programlisting>
+pam_account_locked_message = Account locked, please call help desk.
</programlisting>
</para>
<para>
Default: none
</para>
</listitem>
</varlistentry>
<varlistentry> <term>p11_child_timeout (integer)</term> <listitem> <para>
The rest of the patch looks good to me and seems to work as advertized.
Thanks.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
Patch set with amended commit message. Commit message was acked by AB.
On 02/12/2016 02:19 PM, Pavel Reichl wrote:
On 02/09/2016 04:25 PM, Pavel Reichl wrote:
On 02/09/2016 08:09 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote:
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, please call help desk. </listitem> </varlistentry> <varlistentry>
<term>pam_account_locked_message (string)</term>
<listitem>
<para>
If user is authenticating and
Please ask someone for an English review (I know Dan started, but I didn't see a fixed version yet). At the very least, this should read "a user".
I attached Dan's patch. I took the liberty of adding note regarding pam verbosity. Hope it's fine by Dan.
account is locked then by default
'Permission denied' is output. This output will
be changed to content of this variable if it is
set.
</para>
<para>
example:
<programlisting>
+pam_account_locked_message = Account locked, please call help desk.
</programlisting>
</para>
<para>
Default: none
</para>
</listitem>
</varlistentry>
<varlistentry> <term>p11_child_timeout (integer)</term> <listitem> <para>
The rest of the patch looks good to me and seems to work as advertized.
Thanks.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
Patch set with amended commit message. Commit message was acked by AB.
Lukas asked me for adding comment regarding documenting '775' string to the code. Please see updated patch set. Thanks.
On Fri, Feb 12, 2016 at 02:37:05PM +0100, Pavel Reichl wrote:
On 02/12/2016 02:19 PM, Pavel Reichl wrote:
On 02/09/2016 04:25 PM, Pavel Reichl wrote:
On 02/09/2016 08:09 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote:
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, please call help desk. </listitem> </varlistentry> <varlistentry>
<term>pam_account_locked_message (string)</term>
<listitem>
<para>
If user is authenticating and
Please ask someone for an English review (I know Dan started, but I didn't see a fixed version yet). At the very least, this should read "a user".
I attached Dan's patch. I took the liberty of adding note regarding pam verbosity. Hope it's fine by Dan.
account is locked then by default
'Permission denied' is output. This output will
be changed to content of this variable if it is
set.
</para>
<para>
example:
<programlisting>
+pam_account_locked_message = Account locked, please call help desk.
</programlisting>
</para>
<para>
Default: none
</para>
</listitem>
</varlistentry>
<varlistentry> <term>p11_child_timeout (integer)</term> <listitem> <para>
The rest of the patch looks good to me and seems to work as advertized.
Thanks.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
Patch set with amended commit message. Commit message was acked by AB.
Lukas asked me for adding comment regarding documenting '775' string to the code. Please see updated patch set. Thanks.
I think we've reviewed these patches enough :)
ACK
CI link: http://sssd-ci.duckdns.org/logs/job/37/40/summary.html
On (17/02/16 13:54), Jakub Hrozek wrote:
On Fri, Feb 12, 2016 at 02:37:05PM +0100, Pavel Reichl wrote:
On 02/12/2016 02:19 PM, Pavel Reichl wrote:
On 02/09/2016 04:25 PM, Pavel Reichl wrote:
On 02/09/2016 08:09 AM, Jakub Hrozek wrote:
On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote:
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, please call help desk. </listitem> </varlistentry> <varlistentry>
<term>pam_account_locked_message (string)</term>
<listitem>
<para>
If user is authenticating and
Please ask someone for an English review (I know Dan started, but I didn't see a fixed version yet). At the very least, this should read "a user".
I attached Dan's patch. I took the liberty of adding note regarding pam verbosity. Hope it's fine by Dan.
account is locked then by default
'Permission denied' is output. This output will
be changed to content of this variable if it is
set.
</para>
<para>
example:
<programlisting>
+pam_account_locked_message = Account locked, please call help desk.
</programlisting>
</para>
<para>
Default: none
</para>
</listitem>
</varlistentry>
<varlistentry> <term>p11_child_timeout (integer)</term> <listitem> <para>
The rest of the patch looks good to me and seems to work as advertized.
Thanks.
Patch set with amended commit message. Commit message was acked by AB.
Lukas asked me for adding comment regarding documenting '775' string to the code. Please see updated patch set. Thanks.
I think we've reviewed these patches enough :)
ACK
CI link: http://sssd-ci.duckdns.org/logs/job/37/40/summary.html
master: * 09092b6535b711b9b734ed0c047c671de9e6cafd * 4180d485829969d4626cc7d49d2b5f7146512f21 * ff275f4c0b8cc1a098dbd0c5f6d52d6a93cda597
sssd-1-13: * ffe3df61d85c2890a31d627c5e6fe8890f1e26d8 * 1b9f294dab02e6bcd4ce54e3447648d3d664ceaa * 81cb4057920c6296b7f7e6b7c651fdb601ff0338
LS
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
bye, Sumit
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Mon, 08 Feb 2016, Sumit Bose wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308 should be in the error string and this is what you have to compare against.
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd... ----------------------------------------------------------------------- Regarding the references in MS-ADTS on how account lockout policy is applied on Bind requests, I reported this as a document bug to the product team to request references being added.
For LDAP errors returned by the server on a Simple Bind when the account is locked, the error is the same as if the Bind provided a wrong password. Windows Active Directory returns the LDAP error invalidCredentials.
LDAP Bind Response error codes are documented in RFC2251 4.2.3.. Examples of errors are operationsError , strongAuthRequired, inappropriateAuthentication, invalidCredentials, unavailable.
RFC2251 4.2.3. Bind Response - invalidCredentials: the wrong password was supplied or the SASL credentials could not be processed. The extended error information looks like this: ----------- res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3 Error <49>: ldap_simple_bind_s() failed: Invalid Credentials Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db0 Error 0x80090308 The token supplied to the function is invalid -----------
MS-ERREF 0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is invalid.
The product team will be reflecting this in a future refresh of the MS-ADTS document. -----------------------------------------------------------------------
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
I'll check with Edgar on why this piece is still missing from MS-ADTS five years after. ;)
On Wed, 10 Feb 2016, Alexander Bokovoy wrote:
On Mon, 08 Feb 2016, Sumit Bose wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
Could you add link to msdn documentation where it is described that this string is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308 should be in the error string and this is what you have to compare against.
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd...
Regarding the references in MS-ADTS on how account lockout policy is applied on Bind requests, I reported this as a document bug to the product team to request references being added.
For LDAP errors returned by the server on a Simple Bind when the account is locked, the error is the same as if the Bind provided a wrong password. Windows Active Directory returns the LDAP error invalidCredentials.
LDAP Bind Response error codes are documented in RFC2251 4.2.3.. Examples of errors are operationsError , strongAuthRequired, inappropriateAuthentication, invalidCredentials, unavailable.
RFC2251 4.2.3. Bind Response
- invalidCredentials: the wrong password was supplied or the SASL
credentials could not be processed. The extended error information looks like this:
res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3 Error <49>: ldap_simple_bind_s() failed: Invalid Credentials Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db0 Error 0x80090308 The token supplied to the function is invalid
MS-ERREF 0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is invalid.
The product team will be reflecting this in a future refresh of the MS-ADTS document.
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
I'll check with Edgar on why this piece is still missing from MS-ADTS five years after. ;)
So I re-read MS-ADTS and section 3.1.1.3.1.9 "Error Message Strings" has all the information: ----------------------------------------------------------------------- When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32- bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field. ------------------------------------------------------------------------
So, my comment stands: check for "80090308" in the beginning of errorMessage string.
On Wed, Feb 10, 2016 at 10:45:39AM +0200, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Alexander Bokovoy wrote:
On Mon, 08 Feb 2016, Sumit Bose wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
>Could you add link to msdn documentation where it is described that this string >is guaranted to be returned in such case?
It's not MSDN, but: http://www-01.ibm.com/support/docview.wss?uid=swg21290631
I would prefer official documantation (msdn) in code ar at least in commit message.
We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308 should be in the error string and this is what you have to compare against.
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd...
Regarding the references in MS-ADTS on how account lockout policy is applied on Bind requests, I reported this as a document bug to the product team to request references being added.
For LDAP errors returned by the server on a Simple Bind when the account is locked, the error is the same as if the Bind provided a wrong password. Windows Active Directory returns the LDAP error invalidCredentials.
LDAP Bind Response error codes are documented in RFC2251 4.2.3.. Examples of errors are operationsError , strongAuthRequired, inappropriateAuthentication, invalidCredentials, unavailable.
RFC2251 4.2.3. Bind Response
- invalidCredentials: the wrong password was supplied or the SASL
credentials could not be processed. The extended error information looks like this:
res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3 Error <49>: ldap_simple_bind_s() failed: Invalid Credentials Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db0 Error 0x80090308 The token supplied to the function is invalid
MS-ERREF 0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is invalid.
The product team will be reflecting this in a future refresh of the MS-ADTS document.
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
I'll check with Edgar on why this piece is still missing from MS-ADTS five years after. ;)
So I re-read MS-ADTS and section 3.1.1.3.1.9 "Error Message Strings" has all the information:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32- bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
So, my comment stands: check for "80090308" in the beginning of errorMessage string.
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm afraid just checking for 80090308 is not sufficient as you can see from http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . The value behind the 'data' string is really important to find out the real reason for the denial. The values themselve like (0x)701, (0x)773 or (0x)775 are documented as well (although I do not have the link at hand). But since getting those values requires to parse the string it would be nice to get some official details about the string.
bye, Sumit
-- / Alexander Bokovoy
On 02/10/2016 10:26 AM, Sumit Bose wrote:
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm afraid just checking for 80090308 is not sufficient as you can see from http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . The value behind the 'data' string is really important to find out the real reason for the denial. The values themselve like (0x)701, (0x)773 or (0x)775 are documented as well (although I do not have the link at hand). But
I suppose you mean https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... (ERROR_ACCOUNT_LOCKED_OUT)
since getting those values requires to parse the string it would be nice to get some official details about the string.
bye, Sumit
-- / Alexander Bokovoy
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Wed, Feb 10, 2016 at 10:29:12AM +0100, Pavel Reichl wrote:
On 02/10/2016 10:26 AM, Sumit Bose wrote:
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm afraid just checking for 80090308 is not sufficient as you can see from http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . The value behind the 'data' string is really important to find out the real reason for the denial. The values themselve like (0x)701, (0x)773 or (0x)775 are documented as well (although I do not have the link at hand). But
I suppose you mean https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... (ERROR_ACCOUNT_LOCKED_OUT)
yes, thank you.
bye, Sumit
since getting those values requires to parse the string it would be nice to get some official details about the string.
bye, Sumit
-- / Alexander Bokovoy
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Wed, 10 Feb 2016, Sumit Bose wrote:
On Wed, Feb 10, 2016 at 10:45:39AM +0200, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Alexander Bokovoy wrote:
On Mon, 08 Feb 2016, Sumit Bose wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
> The ticket is about "SSSD should be about to display message to the user when the account in Active Directory is 'locked out'"
If the string is not standardized among AD versions than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
>>Could you add link to msdn documentation where it is described that this string >>is guaranted to be returned in such case? > >It's not MSDN, but: > http://www-01.ibm.com/support/docview.wss?uid=swg21290631 I would prefer official documantation (msdn) in code ar at least in commit message.
We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308 should be in the error string and this is what you have to compare against.
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd...
Regarding the references in MS-ADTS on how account lockout policy is applied on Bind requests, I reported this as a document bug to the product team to request references being added.
For LDAP errors returned by the server on a Simple Bind when the account is locked, the error is the same as if the Bind provided a wrong password. Windows Active Directory returns the LDAP error invalidCredentials.
LDAP Bind Response error codes are documented in RFC2251 4.2.3.. Examples of errors are operationsError , strongAuthRequired, inappropriateAuthentication, invalidCredentials, unavailable.
RFC2251 4.2.3. Bind Response
- invalidCredentials: the wrong password was supplied or the SASL
credentials could not be processed. The extended error information looks like this:
res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3 Error <49>: ldap_simple_bind_s() failed: Invalid Credentials Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db0 Error 0x80090308 The token supplied to the function is invalid
MS-ERREF 0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is invalid.
The product team will be reflecting this in a future refresh of the MS-ADTS document.
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
I'll check with Edgar on why this piece is still missing from MS-ADTS five years after. ;)
So I re-read MS-ADTS and section 3.1.1.3.1.9 "Error Message Strings" has all the information:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32- bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
So, my comment stands: check for "80090308" in the beginning of errorMessage string.
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm afraid just checking for 80090308 is not sufficient as you can see from http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . The value behind the 'data' string is really important to find out the real reason for the denial. The values themselve like (0x)701, (0x)773 or (0x)775 are documented as well (although I do not have the link at hand). But since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
On 02/10/2016 10:38 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Sumit Bose wrote:
On Wed, Feb 10, 2016 at 10:45:39AM +0200, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Alexander Bokovoy wrote:
On Mon, 08 Feb 2016, Sumit Bose wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote: >> >The ticket is about "SSSD should be about to display message to the user when >the account in Active Directory is 'locked out'" > >If the string is not standardized among AD versions >than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
> >>>Could you add link to msdn documentation where it is described that this string >>>is guaranted to be returned in such case? >> >>It's not MSDN, but: >> http://www-01.ibm.com/support/docview.wss?uid=swg21290631 >I would prefer official documantation (msdn) in code ar at least in >commit message.
We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308 should be in the error string and this is what you have to compare against.
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd...
Regarding the references in MS-ADTS on how account lockout policy is applied on Bind requests, I reported this as a document bug to the product team to request references being added.
For LDAP errors returned by the server on a Simple Bind when the account is locked, the error is the same as if the Bind provided a wrong password. Windows Active Directory returns the LDAP error invalidCredentials.
LDAP Bind Response error codes are documented in RFC2251 4.2.3.. Examples of errors are operationsError , strongAuthRequired, inappropriateAuthentication, invalidCredentials, unavailable.
RFC2251 4.2.3. Bind Response
- invalidCredentials: the wrong password was supplied or the SASL
credentials could not be processed. The extended error information looks like this:
res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3 Error <49>: ldap_simple_bind_s() failed: Invalid Credentials Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db0 Error 0x80090308 The token supplied to the function is invalid
MS-ERREF 0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is invalid.
The product team will be reflecting this in a future refresh of the MS-ADTS document.
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
I'll check with Edgar on why this piece is still missing from MS-ADTS five years after. ;)
So I re-read MS-ADTS and section 3.1.1.3.1.9 "Error Message Strings" has all the information:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32- bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
So, my comment stands: check for "80090308" in the beginning of errorMessage string.
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm afraid just checking for 80090308 is not sufficient as you can see from http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . The value behind the 'data' string is really important to find out the real reason for the denial. The values themselve like (0x)701, (0x)773 or (0x)775 are documented as well (although I do not have the link at hand). But since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Alexander thanks for looking into this, but what we need is to distinguish between reasons for invalid credentials.
e.g. Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
On Wed, 10 Feb 2016, Pavel Reichl wrote:
since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Alexander thanks for looking into this, but what we need is to distinguish between reasons for invalid credentials.
e.g. Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
As I said, you should not rely on the information being available to you as it might be disabled completely by the AD administrators in ndsHeuristics attribute.
What are you going to do when ulHideDSID flag is set to 1?
On 02/10/2016 11:06 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Alexander thanks for looking into this, but what we need is to distinguish between reasons for invalid credentials.
e.g. Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
As I said, you should not rely on the information being available to you as it might be disabled completely by the AD administrators in ndsHeuristics attribute.
What are you going to do when ulHideDSID flag is set to 1?
The ticket is about providing extra info to user if account is locked. If we can't decide, we return generic access denied and generic message. Best afford attitude is fine here...IMO.
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:06 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Alexander thanks for looking into this, but what we need is to distinguish between reasons for invalid credentials.
e.g. Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
As I said, you should not rely on the information being available to you as it might be disabled completely by the AD administrators in ndsHeuristics attribute.
What are you going to do when ulHideDSID flag is set to 1?
The ticket is about providing extra info to user if account is locked. If we can't decide, we return generic access denied and generic message. Best afford attitude is fine here...IMO.
That's fine but please add documentation about the behavior into the commit message so that we would have this discussion recorded somehow.
On 02/10/2016 11:46 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:06 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Alexander thanks for looking into this, but what we need is to distinguish between reasons for invalid credentials.
e.g. Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
As I said, you should not rely on the information being available to you as it might be disabled completely by the AD administrators in ndsHeuristics attribute.
What are you going to do when ulHideDSID flag is set to 1?
The ticket is about providing extra info to user if account is locked. If we can't decide, we return generic access denied and generic message. Best afford attitude is fine here...IMO.
That's fine but please add documentation about the behavior into the commit message so that we would have this discussion recorded somehow.
OK, would this:
""" This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators. """
appended to the commit message of the first patch work for you?
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:46 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:06 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
>since getting those values requires to parse the string it would be nice >to get some official details about the string. Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Alexander thanks for looking into this, but what we need is to distinguish between reasons for invalid credentials.
e.g. Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
As I said, you should not rely on the information being available to you as it might be disabled completely by the AD administrators in ndsHeuristics attribute.
What are you going to do when ulHideDSID flag is set to 1?
The ticket is about providing extra info to user if account is locked. If we can't decide, we return generic access denied and generic message. Best afford attitude is fine here...IMO.
That's fine but please add documentation about the behavior into the commit message so that we would have this discussion recorded somehow.
OK, would this:
""" This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators. """
appended to the commit message of the first patch work for you?
Please refer to specific parts of MS-ADTS I've mentioned.
On 02/10/2016 02:34 PM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:46 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:06 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
>> since getting those values requires to parse the string it would be nice >> to get some official details about the string. > Well, the string content after DSID-<number> mark can be completely > missing while the hex of the code (80090308) will be there. > > The presence of "DSID-<number> ..." error message is regulated by > ulHideDSID character of the dsHeuristics attribute (MS-ADTS > 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> > string is completely missing but Win32 code for the error is there. >
Alexander thanks for looking into this, but what we need is to distinguish between reasons for invalid credentials.
e.g. Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
As I said, you should not rely on the information being available to you as it might be disabled completely by the AD administrators in ndsHeuristics attribute.
What are you going to do when ulHideDSID flag is set to 1?
The ticket is about providing extra info to user if account is locked. If we can't decide, we return generic access denied and generic message. Best afford attitude is fine here...IMO.
That's fine but please add documentation about the behavior into the commit message so that we would have this discussion recorded somehow.
OK, would this:
""" This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators. """
appended to the commit message of the first patch work for you?
Please refer to specific parts of MS-ADTS I've mentioned.
OK Alexander, would following work as commit message for you?
This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators.
If account is locked bind operation is expected to return following error message:
------------------------------------------------------------------------- Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0 -------------------------------------------------------------------------
Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. However the 80090308 (error code 0x80090308, SEC_E_INVALID_TOKEN) is the only guaranteed part of error string [2].
Error message is described in further detail as [3]: ------------------------------------------------------------------------- When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32-bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field. -------------------------------------------------------------------------
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... [2] https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd... [3] MS-ADTS 3.1.1.3.1.9 https://msdn.microsoft.com/en-us/library/cc223253.aspx
----- Original Message -----
On 02/10/2016 02:34 PM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:46 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:06 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote: >>> since getting those values requires to parse the string it would be >>> nice >>> to get some official details about the string. >> Well, the string content after DSID-<number> mark can be completely >> missing while the hex of the code (80090308) will be there. >> >> The presence of "DSID-<number> ..." error message is regulated by >> ulHideDSID character of the dsHeuristics attribute (MS-ADTS >> 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> >> string is completely missing but Win32 code for the error is there. >> > > Alexander thanks for looking into this, but what we need is to > distinguish between reasons for invalid credentials. > > e.g. > Bind result: Invalid credentials(49), 80090308: LdapErr: > DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 > Bind result: Invalid credentials(49), 80090308: LdapErr: > DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0 As I said, you should not rely on the information being available to you as it might be disabled completely by the AD administrators in ndsHeuristics attribute.
What are you going to do when ulHideDSID flag is set to 1?
The ticket is about providing extra info to user if account is locked. If we can't decide, we return generic access denied and generic message. Best afford attitude is fine here...IMO.
That's fine but please add documentation about the behavior into the commit message so that we would have this discussion recorded somehow.
OK, would this:
""" This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators. """
appended to the commit message of the first patch work for you?
Please refer to specific parts of MS-ADTS I've mentioned.
OK Alexander, would following work as commit message for you?
This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators.
If account is locked bind operation is expected to return following error message:
Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. However the 80090308 (error code 0x80090308, SEC_E_INVALID_TOKEN) is the only guaranteed part of error string [2].
Error message is described in further detail as [3]:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32-bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... [2] https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd... [3] MS-ADTS 3.1.1.3.1.9 https://msdn.microsoft.com/en-us/library/cc223253.aspx
Pavel, this is great!
Thank you!
On (11/02/16 15:30), Alexander Bokovoy wrote:
----- Original Message -----
On 02/10/2016 02:34 PM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:46 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:06 AM, Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, Pavel Reichl wrote: >>>> since getting those values requires to parse the string it would be >>>> nice >>>> to get some official details about the string. >>> Well, the string content after DSID-<number> mark can be completely >>> missing while the hex of the code (80090308) will be there. >>> >>> The presence of "DSID-<number> ..." error message is regulated by >>> ulHideDSID character of the dsHeuristics attribute (MS-ADTS >>> 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> >>> string is completely missing but Win32 code for the error is there. >>> >> >> Alexander thanks for looking into this, but what we need is to >> distinguish between reasons for invalid credentials. >> >> e.g. >> Bind result: Invalid credentials(49), 80090308: LdapErr: >> DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 >> Bind result: Invalid credentials(49), 80090308: LdapErr: >> DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0 > As I said, you should not rely on the information being available to > you > as it might be disabled completely by the AD administrators in > ndsHeuristics attribute. > > What are you going to do when ulHideDSID flag is set to 1? The ticket is about providing extra info to user if account is locked. If we can't decide, we return generic access denied and generic message. Best afford attitude is fine here...IMO.
That's fine but please add documentation about the behavior into the commit message so that we would have this discussion recorded somehow.
OK, would this:
""" This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators. """
appended to the commit message of the first patch work for you?
Please refer to specific parts of MS-ADTS I've mentioned.
OK Alexander, would following work as commit message for you?
This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators.
If account is locked bind operation is expected to return following error message:
Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. However the 80090308 (error code 0x80090308, SEC_E_INVALID_TOKEN) is the only guaranteed part of error string [2].
Error message is described in further detail as [3]:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32-bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... [2] https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd... [3] MS-ADTS 3.1.1.3.1.9 https://msdn.microsoft.com/en-us/library/cc223253.aspx
Pavel, this is great!
I like it too.
Please do not forget to use just 72 columns in commit message http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
It would be also godd to add links to the related code "data 775".
LS
On 02/12/2016 09:00 AM, Lukas Slebodnik wrote:
On (11/02/16 15:30), Alexander Bokovoy wrote:
----- Original Message -----
On 02/10/2016 02:34 PM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:46 AM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote: > > > On 02/10/2016 11:06 AM, Alexander Bokovoy wrote: >> On Wed, 10 Feb 2016, Pavel Reichl wrote: >>>>> since getting those values requires to parse the string it would be >>>>> nice >>>>> to get some official details about the string. >>>> Well, the string content after DSID-<number> mark can be completely >>>> missing while the hex of the code (80090308) will be there. >>>> >>>> The presence of "DSID-<number> ..." error message is regulated by >>>> ulHideDSID character of the dsHeuristics attribute (MS-ADTS >>>> 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> >>>> string is completely missing but Win32 code for the error is there. >>>> >>> >>> Alexander thanks for looking into this, but what we need is to >>> distinguish between reasons for invalid credentials. >>> >>> e.g. >>> Bind result: Invalid credentials(49), 80090308: LdapErr: >>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 >>> Bind result: Invalid credentials(49), 80090308: LdapErr: >>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0 >> As I said, you should not rely on the information being available to >> you >> as it might be disabled completely by the AD administrators in >> ndsHeuristics attribute. >> >> What are you going to do when ulHideDSID flag is set to 1? > The ticket is about providing extra info to user if account is locked. > If we can't decide, we return generic access denied and generic > message. Best afford attitude is fine here...IMO. That's fine but please add documentation about the behavior into the commit message so that we would have this discussion recorded somehow.
OK, would this:
""" This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators. """
appended to the commit message of the first patch work for you?
Please refer to specific parts of MS-ADTS I've mentioned.
OK Alexander, would following work as commit message for you?
This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators.
If account is locked bind operation is expected to return following error message:
Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. However the 80090308 (error code 0x80090308, SEC_E_INVALID_TOKEN) is the only guaranteed part of error string [2].
Error message is described in further detail as [3]:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32-bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... [2] https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd... [3] MS-ADTS 3.1.1.3.1.9 https://msdn.microsoft.com/en-us/library/cc223253.aspx
Pavel, this is great!
Happy to hear that, thanks for checking the MS-ADTS.
I like it too.
Good :-)
Please do not forget to use just 72 columns in commit message http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Sure.
It would be also godd to add links to the related code "data 775".
Did you miss: "... Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. ..." or you would like me to reword it?
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On (12/02/16 12:54), Pavel Reichl wrote:
On 02/12/2016 09:00 AM, Lukas Slebodnik wrote:
On (11/02/16 15:30), Alexander Bokovoy wrote:
----- Original Message -----
On 02/10/2016 02:34 PM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote:
On 02/10/2016 11:46 AM, Alexander Bokovoy wrote: >On Wed, 10 Feb 2016, Pavel Reichl wrote: >> >> >>On 02/10/2016 11:06 AM, Alexander Bokovoy wrote: >>>On Wed, 10 Feb 2016, Pavel Reichl wrote: >>>>>>since getting those values requires to parse the string it would be >>>>>>nice >>>>>>to get some official details about the string. >>>>>Well, the string content after DSID-<number> mark can be completely >>>>>missing while the hex of the code (80090308) will be there. >>>>> >>>>>The presence of "DSID-<number> ..." error message is regulated by >>>>>ulHideDSID character of the dsHeuristics attribute (MS-ADTS >>>>>6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> >>>>>string is completely missing but Win32 code for the error is there. >>>>> >>>> >>>>Alexander thanks for looking into this, but what we need is to >>>>distinguish between reasons for invalid credentials. >>>> >>>>e.g. >>>>Bind result: Invalid credentials(49), 80090308: LdapErr: >>>>DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 >>>>Bind result: Invalid credentials(49), 80090308: LdapErr: >>>>DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0 >>>As I said, you should not rely on the information being available to >>>you >>>as it might be disabled completely by the AD administrators in >>>ndsHeuristics attribute. >>> >>>What are you going to do when ulHideDSID flag is set to 1? >>The ticket is about providing extra info to user if account is locked. >>If we can't decide, we return generic access denied and generic >>message. Best afford attitude is fine here...IMO. >That's fine but please add documentation about the behavior into the >commit message so that we would have this discussion recorded somehow. >
OK, would this:
""" This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators. """
appended to the commit message of the first patch work for you?
Please refer to specific parts of MS-ADTS I've mentioned.
OK Alexander, would following work as commit message for you?
This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators.
If account is locked bind operation is expected to return following error message:
Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. However the 80090308 (error code 0x80090308, SEC_E_INVALID_TOKEN) is the only guaranteed part of error string [2].
Error message is described in further detail as [3]:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32-bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... [2] https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd... [3] MS-ADTS 3.1.1.3.1.9 https://msdn.microsoft.com/en-us/library/cc223253.aspx
Pavel, this is great!
Happy to hear that, thanks for checking the MS-ADTS.
I like it too.
Good :-)
Please do not forget to use just 72 columns in commit message http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Sure.
It would be also godd to add links to the related code "data 775".
Did you miss: "... Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. ..." or you would like me to reword it?
I meant that simple comment in related code might be useful too. As we have in other places in code.
e.g. src/providers/ldap/sdap_async.h 342 /* OID documented in 343 * http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475%28v=vs.8 5%29.aspx 344 */ 345 #define SDAP_MATCHING_RULE_IN_CHAIN "1.2.840.113556.1.4.1941"
And If someone would like to see more details then they can be found either in commit message or in provided links.
LS
On 02/12/2016 02:17 PM, Lukas Slebodnik wrote:
On (12/02/16 12:54), Pavel Reichl wrote:
On 02/12/2016 09:00 AM, Lukas Slebodnik wrote:
On (11/02/16 15:30), Alexander Bokovoy wrote:
----- Original Message -----
On 02/10/2016 02:34 PM, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Pavel Reichl wrote: > > > On 02/10/2016 11:46 AM, Alexander Bokovoy wrote: >> On Wed, 10 Feb 2016, Pavel Reichl wrote: >>> >>> >>> On 02/10/2016 11:06 AM, Alexander Bokovoy wrote: >>>> On Wed, 10 Feb 2016, Pavel Reichl wrote: >>>>>>> since getting those values requires to parse the string it would be >>>>>>> nice >>>>>>> to get some official details about the string. >>>>>> Well, the string content after DSID-<number> mark can be completely >>>>>> missing while the hex of the code (80090308) will be there. >>>>>> >>>>>> The presence of "DSID-<number> ..." error message is regulated by >>>>>> ulHideDSID character of the dsHeuristics attribute (MS-ADTS >>>>>> 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> >>>>>> string is completely missing but Win32 code for the error is there. >>>>>> >>>>> >>>>> Alexander thanks for looking into this, but what we need is to >>>>> distinguish between reasons for invalid credentials. >>>>> >>>>> e.g. >>>>> Bind result: Invalid credentials(49), 80090308: LdapErr: >>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 773, v23f0 >>>>> Bind result: Invalid credentials(49), 80090308: LdapErr: >>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0 >>>> As I said, you should not rely on the information being available to >>>> you >>>> as it might be disabled completely by the AD administrators in >>>> ndsHeuristics attribute. >>>> >>>> What are you going to do when ulHideDSID flag is set to 1? >>> The ticket is about providing extra info to user if account is locked. >>> If we can't decide, we return generic access denied and generic >>> message. Best afford attitude is fine here...IMO. >> That's fine but please add documentation about the behavior into the >> commit message so that we would have this discussion recorded somehow. >> > > OK, would this: > > """ > This patch is best effort only as decision whether account is actually > locked is based on parsing error message returned by AD. The format and > content of this error message might be subject of change in future > releases and also can be modified by > AD administrators. > """ > > appended to the commit message of the first patch work for you? Please refer to specific parts of MS-ADTS I've mentioned.
OK Alexander, would following work as commit message for you?
This patch is best effort only as decision whether account is actually locked is based on parsing error message returned by AD. The format and content of this error message might be subject of change in future releases and also can be modified by AD administrators.
If account is locked bind operation is expected to return following error message:
Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 775, v23f0
Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. However the 80090308 (error code 0x80090308, SEC_E_INVALID_TOKEN) is the only guaranteed part of error string [2].
Error message is described in further detail as [3]:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32-bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs.85%... [2] https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd... [3] MS-ADTS 3.1.1.3.1.9 https://msdn.microsoft.com/en-us/library/cc223253.aspx
Pavel, this is great!
Happy to hear that, thanks for checking the MS-ADTS.
I like it too.
Good :-)
Please do not forget to use just 72 columns in commit message http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Sure.
It would be also godd to add links to the related code "data 775".
Did you miss: "... Where sub string 'data 775' implies that account is locked (ERROR_ACCOUNT_LOCKED_OUT) [1]. ..." or you would like me to reword it?
I meant that simple comment in related code might be useful too. As we have in other places in code.
e.g. src/providers/ldap/sdap_async.h 342 /* OID documented in 343 * http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475%28v=vs.8 5%29.aspx 344 */ 345 #define SDAP_MATCHING_RULE_IN_CHAIN "1.2.840.113556.1.4.1941"
And If someone would like to see more details then they can be found either in commit message or in provided links.
OK, I see, I'll send updated patch set.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Wed, Feb 10, 2016 at 11:38:34AM +0200, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Sumit Bose wrote:
On Wed, Feb 10, 2016 at 10:45:39AM +0200, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Alexander Bokovoy wrote:
On Mon, 08 Feb 2016, Sumit Bose wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
On 02/05/2016 03:16 PM, Lukas Slebodnik wrote: >> >The ticket is about "SSSD should be about to display message to the user when >the account in Active Directory is 'locked out'" > >If the string is not standardized among AD versions >than this ticket is NOT solved.
So what do you propose? Rename ticket to contain version of tested AD? Or should we say user that although we have fix that would work for him it might not work for all AD versions so we won't provide it?
Can we ask our QA to test on all AD version they can lay their hands on?
> >>>Could you add link to msdn documentation where it is described that this string >>>is guaranted to be returned in such case? >> >>It's not MSDN, but: >> http://www-01.ibm.com/support/docview.wss?uid=swg21290631 >I would prefer official documantation (msdn) in code ar at least in >commit message.
We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308 should be in the error string and this is what you have to compare against.
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd...
Regarding the references in MS-ADTS on how account lockout policy is applied on Bind requests, I reported this as a document bug to the product team to request references being added.
For LDAP errors returned by the server on a Simple Bind when the account is locked, the error is the same as if the Bind provided a wrong password. Windows Active Directory returns the LDAP error invalidCredentials.
LDAP Bind Response error codes are documented in RFC2251 4.2.3.. Examples of errors are operationsError , strongAuthRequired, inappropriateAuthentication, invalidCredentials, unavailable.
RFC2251 4.2.3. Bind Response
- invalidCredentials: the wrong password was supplied or the SASL
credentials could not be processed. The extended error information looks like this:
res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3 Error <49>: ldap_simple_bind_s() failed: Invalid Credentials Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db0 Error 0x80090308 The token supplied to the function is invalid
MS-ERREF 0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is invalid.
The product team will be reflecting this in a future refresh of the MS-ADTS document.
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
I'll check with Edgar on why this piece is still missing from MS-ADTS five years after. ;)
So I re-read MS-ADTS and section 3.1.1.3.1.9 "Error Message Strings" has all the information:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32- bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
So, my comment stands: check for "80090308" in the beginning of errorMessage string.
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm afraid just checking for 80090308 is not sufficient as you can see from http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . The value behind the 'data' string is really important to find out the real reason for the denial. The values themselve like (0x)701, (0x)773 or (0x)775 are documented as well (although I do not have the link at hand). But since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Interesting, so it is basically a best effort. If there server sends sufficient information which we know and can handle we can tell the user that his account is locked and that he has to try later. Otherwise he will just see an authentication error. But I think this is fine and the current version of the patch already behaves like this.
bye, Sumit
-- / Alexander Bokovoy
On Wed, 10 Feb 2016, Sumit Bose wrote:
On Wed, Feb 10, 2016 at 11:38:34AM +0200, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Sumit Bose wrote:
On Wed, Feb 10, 2016 at 10:45:39AM +0200, Alexander Bokovoy wrote:
On Wed, 10 Feb 2016, Alexander Bokovoy wrote:
On Mon, 08 Feb 2016, Sumit Bose wrote:
On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote: > > >On 02/05/2016 03:16 PM, Lukas Slebodnik wrote: >>> >>The ticket is about "SSSD should be about to display message to the user when >>the account in Active Directory is 'locked out'" >> >>If the string is not standardized among AD versions >>than this ticket is NOT solved. > >So what do you propose? Rename ticket to contain version of tested >AD? Or should we say user that although we have fix that would work >for him it might not work for all AD versions so we won't provide it? > >Can we ask our QA to test on all AD version they can lay their hands on? > >> >>>>Could you add link to msdn documentation where it is described that this string >>>>is guaranted to be returned in such case? >>> >>>It's not MSDN, but: >>> http://www-01.ibm.com/support/docview.wss?uid=swg21290631 >>I would prefer official documantation (msdn) in code ar at least in >>commit message. > >We don't have any and it's possible it's not publicly documented.
The '755' in the message is a specific error code of some AD calls which can be seen by the link Dan send. So I guess this will not change.
While I can make sense of some part of the remaining error string (yes, it is just a string send with the LDAP bind response) I didn't found any general description of the format and the components of the error string on the MSFT sites.
You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308 should be in the error string and this is what you have to compare against.
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd...
Regarding the references in MS-ADTS on how account lockout policy is applied on Bind requests, I reported this as a document bug to the product team to request references being added.
For LDAP errors returned by the server on a Simple Bind when the account is locked, the error is the same as if the Bind provided a wrong password. Windows Active Directory returns the LDAP error invalidCredentials.
LDAP Bind Response error codes are documented in RFC2251 4.2.3.. Examples of errors are operationsError , strongAuthRequired, inappropriateAuthentication, invalidCredentials, unavailable.
RFC2251 4.2.3. Bind Response
- invalidCredentials: the wrong password was supplied or the SASL
credentials could not be processed. The extended error information looks like this:
res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3 Error <49>: ldap_simple_bind_s() failed: Invalid Credentials Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db0 Error 0x80090308 The token supplied to the function is invalid
MS-ERREF 0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is invalid.
The product team will be reflecting this in a future refresh of the MS-ADTS document.
Alexander, do you think it would make sense to ask MSFT to enhance the documentation of the LDAP error message format? And if yes, is sending an email to dochelp@microsoft.com sufficient or this there a more elaborate process?
I'll check with Edgar on why this piece is still missing from MS-ADTS five years after. ;)
So I re-read MS-ADTS and section 3.1.1.3.1.9 "Error Message Strings" has all the information:
When the server fails an LDAP operation with an error, and the server has sufficient resources to compute a string value for the errorMessage field of the LDAPResult, it includes a string in the errorMessage field of the LDAPResult (see [RFC2251] section 4.1.10). The string contains further information about the error.
The first eight characters of the errorMessage string are a 32-bit integer, expressed in hexadecimal. Where protocol specifies the extended error code "<unrestricted>" there is no restriction on the value of the 32-bit integer. It is recommended that implementations use a Windows error code for the 32-bit integer in this case in order to improve usability of the directory for clients. Where protocol specifies an extended error code which is a Windows error code, the 32- bit integer is the specified Windows error code. Any data after the eighth character is strictly informational and used only for debugging. Conformant implementations need not put any value beyond the eighth character of the errorMessage field.
So, my comment stands: check for "80090308" in the beginning of errorMessage string.
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm afraid just checking for 80090308 is not sufficient as you can see from http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . The value behind the 'data' string is really important to find out the real reason for the denial. The values themselve like (0x)701, (0x)773 or (0x)775 are documented as well (although I do not have the link at hand). But since getting those values requires to parse the string it would be nice to get some official details about the string.
Well, the string content after DSID-<number> mark can be completely missing while the hex of the code (80090308) will be there.
The presence of "DSID-<number> ..." error message is regulated by ulHideDSID character of the dsHeuristics attribute (MS-ADTS 6.1.1.2.4.1.2). So you can have Active Directory where DSID-<number> string is completely missing but Win32 code for the error is there.
Interesting, so it is basically a best effort. If there server sends sufficient information which we know and can handle we can tell the user that his account is locked and that he has to try later. Otherwise he will just see an authentication error. But I think this is fine and the current version of the patch already behaves like this.
I'd like to have a summary why we are depending on the debug string and where logic of it being available/not available could be found to be added to a commit message.
sssd-devel@lists.fedorahosted.org