Add a security tab on users
Add a security tab on users
Descriptive title for this enhancement
Put a security tab on the users
Actual behavior
No possibility to know the last session, or action made by the user itself on his account
Expected behavior
Have a security tab on the user that show :
- The last login on fusionDirectory
- Active session
- Logs of authentication events
Step by step description of new behaviour
look at attached pictures for an idea
Benefits
The user can check what happened to his account, important for high privileges account but also to reinforce the security aspect of fusiondirectory
Possible Drawbacks
need to design own objectclass and attributes
Applicable Issues
Security
Activity
changed milestone to %FusionDirectory 1.4
By bmortier on 2019-10-30T21:05:19 (imported from GitLab)
added PJ1802-0188 fusiondirectory-core labels
hello @MCMic,
to be more precise about this development we will store in this security tab
- Login - originated from 195.23.12.234 - date time
- Password Changed - date time
- Logout - originated from 195.23.12.234 - date time
we could save that under ou=security,ou=fusiondirectory.
We could then create a security dashboard for manager, listing user and the security actions on their account.
This pose the qestion how to store those objects, we need a new objectClass and attributes and to decide how the dn is constructed.
could be cn=toto,ou=security,ou=fusiondirectory that would allow to create a dashboard showing lasts actions like
dn last login last logout password toto 24-12-2019 25-12-2019 first ideas
By bmortier on 2019-11-05T14:49:56 (imported from GitLab)
Edited by bmortierSo, it appears logins are already logged, and can be audited by adding the «security» action in the audit plugin configuration. Failed logins are supposed to be logged but it crashes with this stacktrace:
<b>Fatal error</b>: Uncaught NonExistingObjectTypeException: Non-existing type "auditEvent" in /usr/share/fusiondirectory/include/class_objects.inc:415 Stack trace: #0 /usr/share/fusiondirectory/include/class_objects.inc(333): objects::infos('auditEvent') #1 /usr/share/fusiondirectory/include/class_objects.inc(391): objects::open('new', 'auditEvent') #2 /usr/share/fusiondirectory/include/class_logging.inc(145): objects::create('auditEvent') #3 /usr/share/fusiondirectory/include/class_logging.inc(88): logging::log_into_ldap(Array) #4 /usr/share/fusiondirectory/include/login/class_LoginMethod.inc(102): logging::log('security', 'login', '', Array, 'Authentication ...') #5 /usr/share/fusiondirectory/include/login/class_LoginMethod.inc(165): LoginMethod::ldapLoginUser() #6 /usr/share/fusiondirectory/include/login/class_LoginPost.inc(46): LoginMethod::runSteps(Array) #7 /usr/share/fusiondirectory/include/login/class_LoginMethod.inc(193): LoginPost::loginProcess() #8 /usr/share/fusiondirectory/html/index.php(152): LoginMethod::loginPro in <b>/usr/share/fusiondirectory/include/class_objects.inc</b> on line <b>415</b><br />What is missing:
- Log/audit logout as well
- Add an easy way to list only security lines in the audit
- Fix the crash
- Store the IP
- Add a tab on users that list related security audit? What if security audit is not enabled? Why not all audit?
- Review logging for special action 'security' and which information goes to which field.
By Côme Chilliet on 2019-11-05T15:41:29 (imported from GitLab)
What is missing:
- Add a tab on users that list related security audit? What if security audit is not enabled? Why not all audit?
if we show all audit it could be huge and not interesting for the user itself the idea is a synthetic view of the security events in your account
By bmortier on 2019-11-05T15:41:29 (imported from GitLab)
mentioned in commit 2e8feb3a
By Côme Chilliet on 2019-11-06T10:27:33 (imported from GitLab)
mentioned in commit 900d9a29
By Côme Chilliet on 2019-11-06T10:27:33 (imported from GitLab)
Login/logout are now logged correctly. The crash is fixed.
Here is what I see in audit now if I log out, try to login with wrong password, then login successfully:
Here is the login event:
Regarding fields and storing the IP: Currently the IP is always stored if available but in the result text, like «User "fd-admin" logged in successfully (from ::1).» and «fd-admin (::1) logged out (Sign out)». Maybe it would be better to always have the IP either in author or target object? (currently author and target object both contain the user dn for successful login/logout, for login failure author contains IP and target contains login.)
Note that changing author content is harder, because this is currently common to all audit (author is always dn of connected user if any, otherwise IP if available). And when opening an audit event the author field links to the user if it contains a DN. For all these reasons I think we should not change content of author field, but we can put the IP in target field if really needed. An other idea is to put it in the fdAuditAttributes which currently stays empty for security logging. We also could add an attribute fdAuthorIP in the fdAuditEvent, it may be the cleanest.
By Côme Chilliet on 2019-11-06T10:35:22 (imported from GitLab)
mentioned in issue fd-plugins#6010 (closed)
By Côme Chilliet on 2019-11-06T10:45:52 (imported from GitLab)
mentioned in commit 0fda6e21
By Côme Chilliet on 2019-11-06T10:54:10 (imported from GitLab)
mentioned in commit 0fdcba32
By Côme Chilliet on 2019-11-06T10:54:11 (imported from GitLab)
mentioned in commit fd2118dd
By Côme Chilliet on 2019-11-06T11:41:10 (imported from GitLab)
mentioned in commit 6253e773
By Côme Chilliet on 2019-11-06T11:42:44 (imported from GitLab)
mentioned in commit a8c281c2
By Côme Chilliet on 2019-11-06T14:17:15 (imported from GitLab)
mentioned in commit 702eed93
By Côme Chilliet on 2019-11-06T14:17:15 (imported from GitLab)
mentioned in commit 85bf237d
By Côme Chilliet on 2019-11-06T16:02:06 (imported from GitLab)
mentioned in commit 2fae8e55
By Côme Chilliet on 2019-11-06T16:02:06 (imported from GitLab)
added To Be Tested label
added packaging label
mentioned in commit afcd9360
By Côme Chilliet on 2019-11-12T10:53:27 (imported from GitLab)
mentioned in commit 74becb80
By Côme Chilliet on 2019-11-12T10:53:27 (imported from GitLab)
mentioned in commit 771dcaac
By Côme Chilliet on 2019-11-12T10:53:27 (imported from GitLab)
assigned to @jswaelens and unassigned @MCMic
By Côme Chilliet on 2019-11-12T13:05:14 (imported from GitLab)
hello,
testing all filter in audit and configured all action in audit.
only the copy / paste create an error
LDAP operation failed! Object: fdAuditDateTime=20191112213832.728041Z,ou=audit,dc=demo-fusiondirectory,dc=org Error: Invalid syntax (fdAuditResult: value #0 invalid per syntax, while operating on "fdAuditDateTime=20191112213832.728041Z,ou=audit,dc=demo-fusiondirectory,dc=org" using LDAP server "ldap://demo-dev.fusiondirectory.org")in the audit list i see this
it would be nice if the new was replace by the actual dn where we are copying ?
Cheers
By bmortier on 2019-11-12T21:44:59 (imported from GitLab)
assigned to @MCMic and unassigned @jswaelens
By bmortier on 2019-11-12T21:45:07 (imported from GitLab)
mentioned in commit cd5e5181
By Côme Chilliet on 2019-11-13T10:34:17 (imported from GitLab)
@bmortier Crash is fixed, and logging is done after paste is successful now, so it contains the dn of the pasted object.
Also, security has been added to default audited actions in audit plugin configuration.
By Côme Chilliet on 2019-11-13T10:48:50 (imported from GitLab)
I get this when editing configuration:
Une erreur irrécupérable s'est produite. Veuillez contacter votre administrateur. NonExistingObjectTypeException: Non-existing type "auditEvent" in /usr/share/fusiondirectory/include/class_objects.inc:415 Stack trace: #0 /usr/share/fusiondirectory/include/class_objects.inc(333): objects::infos('auditEvent') #1 /usr/share/fusiondirectory/include/class_objects.inc(391): objects::open('new', 'auditEvent') #2 /usr/share/fusiondirectory/include/class_logging.inc(142): objects::create('auditEvent') #3 /usr/share/fusiondirectory/include/class_logging.inc(85): logging::log_into_ldap(Array) #4 /usr/share/fusiondirectory/include/php_setup.inc(194): logging::log('error', 'php', '/usr/share/fusi...', Array, 'Type:1024, Mess...') #5 [internal function]: gosaRaiseError(1024, 'Could not set l...', '/usr/share/fusi...', 239, Array) #6 /usr/share/fusiondirectory/include/class_Language.inc(239): trigger_error('Could not set l...') #7 /usr/share/fusiondirectory/include/class_Language.inc(56): Language::setHeaders('fr_FR.UTF-8', 'text/html') #8 /usr/share/fusiondirectory/include/class_config.inc(407): Language::init() #9 /usr/share/fusiondirectory/include/class_config.inc(111): config->set_current('default') #10 /usr/share/fusiondirectory/plugins/config/tabs_configInLdap.inc(29): config->check_and_reload(true) #11 /usr/share/fusiondirectory/include/simpleplugin/class_simplePlugin.inc(2201): tabs_configInLdap->save() #12 /usr/share/fusiondirectory/plugins/config/class_configInLdap.inc(574): simplePlugin::mainInc('configInLdap', 'cn=config,ou=fu...', true, true, 'configuration') #13 /usr/share/fusiondirectory/include/class_pluglist.inc(576): configInLdap::mainInc() #14 /usr/share/fusiondirectory/html/main.php(215): pluglist::runMainInc('37') #15 {main}It tries to log a PHP error to audit before objectTypes are correctly loaded, which breaks everything.
By Côme Chilliet on 2019-11-14T10:44:43 (imported from GitLab)
We need to decide what should happen when the audit logging crash with an exception:
- Crash as above?
- Silently drop the exception, meaning things might silently not be logged (at least not in audit, it will appear in the log)
- (If possible) Show the error in a pop-up, but continue execution.
- Try to see in it each case if catching the exception makes sense or not. (And in the case above, logging PHP errors, catch it)
By Côme Chilliet on 2019-11-20T14:36:37 (imported from GitLab)
