URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
abbra commented:
"""
You are correct in the fact that the search filter need to be modified to allow
matching entries without nsAccountLock attribute set.
"""
See the full
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
HonzaCholasta commented:
"""
I see, I assumed that it's not operational because it's not always set. I stand
corrected, but this information does not change anything in
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
abbra commented:
"""
The nsaccountlock *is* virtual attribute in 389-ds:
attributeTypes: ( 2.16.840.1.113730.3.1.610 NAME 'nsAccountLock'
DESC 'Operational
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
HonzaCholasta commented:
"""
@abbra, the issue is not that the attribute is not requested (it is in fast
always requested in user commands), it is that when the attribute is
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
abbra commented:
"""
Yes, you can add nsaccountlock attribute retrieval in the `pre_callback` and
process it in the `post_callback`. nsaccountlock is an operational attribute
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
redhatrises commented:
"""
Thanks guys. So can this be fixed in `pre_callback` or `post_callback` in
`user_find`, or am I looking elsewhere? (Not super familiar with all of
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
abbra commented:
"""
nsaccountlock is an operational attribute, not a normal one. I don't like it
being created all the time. You have to request it explicitly if you want to
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
HonzaCholasta commented:
"""
No, it's not the right approach. This is an issue in the framework and that's
where it needs to be fixed - in the framework - rather than working
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
MartinBasti commented:
"""
@redhatrises IMO for new users we can always create that attribute in LDAP,
that should limit bad behavior. I wouldn't add it to user-add, usually
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
redhatrises commented:
"""
@MartinBasti sorry for the late reply, but yes, this is a bug. If
'nsaccountlock' doesn't exist, it should return as `Account disabled = False`.
I
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
MartinBasti commented:
"""
Or we can modify search filter on server to cover this case, but it won't be
nice
"""
See the full comment at
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
MartinBasti commented:
"""
I found "not-sure-if" bug, nsaccountlock is not always specified (admin has it
and any user after user-enable, that's why I didn't catch it during
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
MartinBasti commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/a930ec824da0337109d646ab3acb495dc1b6ba63
"""
See the full comment at
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
MartinBasti commented:
"""
@pvomacka IMO this may deserve webUI part too
"""
See the full comment at
https://github.com/freeipa/freeipa/pull/444#issuecomment-279752074
--
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
MartinBasti commented:
"""
LGTM, I'll test it later
"""
See the full comment at
https://github.com/freeipa/freeipa/pull/444#issuecomment-279455811
--
Manage your
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
redhatrises commented:
"""
@MartinBasti I believe that this is ready for your review.
"""
See the full comment at
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
HonzaCholasta commented:
"""
Replacing `flags=['no_option']` with `flags=['no_create', 'no_update']` is not
backward compatible - the `no_option` flag only hides the option in
17 matches
Mail list logo
