I'm looking to setup HBAC for linux servers. People currently login to
the hosts(via ssh) using ssh keys(no password).
I was thinking that one way to control access is by denying the
sshPublicKey(or even the uid, many options here) from being visible on
the host by default, and creating an aci that allows the attribute to be
visible based on the host. The visibility would be controlled by
applying the aci to a group, and if the person is a member, then it's
allowed. This does not work as I hoped though, since there is no bind
performed as the user when the user logs in to the host.
My questions.. 1) if is this a sane approach, how might I get around
this issue? 2) If this is not a good way, what might be a better way to
The caveats are I don't want to rely on posix group membership in the
allowgroups in sshd.conf, nor do I want to require passwords to login
Today we have a global account lockout policy in 389 which is applied
to a specific instance.
With many countries applying different compliance rules for securing
personal data of their cititizen we see an increasing demand to have a
seperate account lockout policy for special types of accounts or to be
applied on a Country specific OU.
Example. If we want to have the accountlockoutduration set to 60 minutes
for a specific OU instead of the standard duration applied on a global
policy , can it be done?
I can see we can apply different password policies but that doesnt cover
the account Lockout policies.
Any help would be appreciated.
Hi I’m in the process of migrating from 389-Directory/126.96.36.199 -> 389-Directory/188.8.131.52. I’m trying to automate the setup. I’m finding that I can no longer enable SSL via the command line using ldapmodify. For V184.108.40.206 setup I followed https://access.redhat.com/documentation/en-us/red_hat_directory_server/10.... After restarting the service, SSL is not enabled. I am able to use the Admin Console to enable SSL. I found that the following is missing from when I setup via ldapmodify vs Admin Console.
Following is missing even after following the RedHat documentation.
# RSA, encryption, config
nsSSLToken: internal (software)
I do notice that when I make the changes via ldapmodify it says that the changes have been successfully made, but they don’t show up in a search before and after a service restart. Also “nsslapd-security” never changes from off to on via command line edit. Here is some info about my system.
OS: CentOS Linux release 7.5.1804 (Core)
389 packages installed:
Version of Directory Server: 389-Directory/220.127.116.11 B2018.269.1826
ldapmodify -x -D "cn=Directory Manager" -w XXXX << EOF
nsSSLToken: internal (software)
systemctl restart dirsrv(a)XXXXX.service
when adding a new entry, the menu already contains entries like user, group or organizational unit, with preselected attributes.
Is possible to add further entries to this menu, e.g. a kopano user with attributes out of the already imported kopano schema?
Thanks for any hints in advance.
My Jira server just forgot all of it’s LDAP settings for no clear reason. While trying to put the settings back, Jira is logging into 389ds by binding as the user "cn=Atlassian,dc=x”.
389ds is in return responding as follows:
[LDAP: error code 48 - Anonymous access is not allowed]; nested exception is javax.naming.AuthenticationNotSupportedException: [LDAP: error code 48 - Anonymous access is not allowed]
[02/Nov/2018:17:11:23 +0200] conn=140630 op=0 BIND dn="cn=Atlassian,dc=x" method=128 version=3
[02/Nov/2018:17:11:23 +0200] conn=140630 op=0 RESULT err=48 tag=97 nentries=0 etime=1
[02/Nov/2018:17:11:23 +0200] conn=140630 op=-1 fd=134 closed - B1
Why would 389ds complain that anonymous access is not allowed on a non-anonymous bind? What am I missing?
(389-ds-base-18.104.22.168-97.el6_10.x86_64 on RHEL6)