Host based authentication not working as desired
by Leonard Lawton
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
accomplish this?
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
5 years, 5 months
Configuring Account lockout policy for a individual user or a specific OU
by Zombie fork
Hi,
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.
5 years, 5 months
Unable to enable SSL using ldapmodify on 389-Directory/1.3.7.5
by Jason Jenkins
Hi I’m in the process of migrating from 389-Directory/1.2.11.15 -> 389-Directory/1.3.7.5. I’m trying to automate the setup. I’m finding that I can no longer enable SSL via the command line using ldapmodify. For V1.3.7.5 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.
nsSSL3: on
nsSSL3Ciphers: -rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+
sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+
,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_exp
56_sha,+tls_rsa_export1024_with_des_cbc_sha,+tls_rsa_aes_128
_256_sha
nsKeyfile: alias/slapd-XXXXX-key3.db
nsCertfile: alias/slapd-XXXXX-cert8.db
# RSA, encryption, config
dn: cn=RSA,cn=encryption,cn=config
nsSSLToken: internal (software)
nsSSLPersonalitySSL: server-cert
nsSSLActivation: on
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
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:
389-adminutil-1.1.21-2.el7.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-admin-console-1.1.12-1.el7.noarch
389-ds-base-libs-1.3.7.5-28.el7_5.x86_64
389-ds-console-1.2.16-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-ds-base-1.3.7.5-28.el7_5.x86_64
389-ds-console-doc-1.2.16-1.el7.noarch
389-admin-1.1.46-1.el7.x86_64
389-console-1.1.18-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
Version of Directory Server: 389-Directory/1.3.7.5 B2018.269.1826
Commands executing:
ldapmodify -x -D "cn=Directory Manager" -w XXXX << EOF
dn: cn=config
changetype: modify
replace: nsslapd-securePort
nsslapd-securePort: 636
-
replace: nsslapd-security
nsslapd-security: on
dn: cn=RSA,cn=encryption,cn=config
changetype: modify
replace: nsSSLToken
nsSSLToken: internal (software)
-
replace: nsSSLPersonalitySSL
nsSSLPersonalitySSL: server-cert
-
replace: nsSSLActivation
nsSSLActivation: on
EOF
systemctl restart dirsrv(a)XXXXX.service
5 years, 5 months
How to define templates and add an entry to the menu?
by "Stefan Günther"
Hello,
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.
Regards,
Stefan
5 years, 5 months
When binding non-anonymously, error code 48 - Anonymous access is not allowed
by Graham Leggett
Hi all,
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-1.2.11.15-97.el6_10.x86_64 on RHEL6)
Regards,
Graham
—
5 years, 5 months
