security

DDOS Attacks leveraging LDAP !

LudoLeave a comment
21382575392_223304551e_z
photo by Christiaan Colen

Yesterday, DDoS mitigation provider Corero Network Security disclosed a zero-day distributed denial of service attack (DDoS) technique, observed in the wild, that is capable of amplifying malicious traffic by a factor of as much as 55x. Several sites published the story as “Attackers are now abusing exposed LDAP servers to amplify DDoS attacks”.

 

According to Corero, the attacks exploited the Lightweight Directory Access Protocol (LDAP), but reading the details of the press release, it appears that the attackers were using Connectionless LDAP services (CLDAP) .

In this case, the attacker sends a simple query to a vulnerable reflector supporting the Connectionless LDAP service (CLDAP) and using address spoofing makes it appear to originate from the intended victim. The CLDAP service responds to the spoofed address, sending unwanted network traffic to the attacker’s intended target.

Connectionless LDAP  is a very old technical specification, published in 1995 as RFC 1798.  In 2003, this specification was obsoleted by RFC 3352 and moved to historical status. One of the main reason for obsoleting the proposed standard was its insufficient security capabilities.

OpenDJ, the open source LDAP Directory Services in Java, has never supported CLDAP and thus cannot be used in such attack. So, if you are a  ForgeRock customer, you should not worry about this kind of attack. But if you’re running a legacy product, that has CLDAP enabled by default, it is probably time to think about moving to a more recent and up to date directory service, such as OpenDJ.

 

Data Confidentiality with OpenDJ LDAP Directory Services

Ludo2 Comments

FR_plogo_org_FC_openDJ-300x86Directory Servers have been used and continue to be used to store and retrieve identity information, including some data that is sensitive and should be protected. OpenDJ LDAP Directory Services, like many directory servers, has an extensive set of features to protect the data, from securing network connections and communications, authenticating users, to access controls and privileges… However, in the last few years, the way LDAP directory services have been deployed and managed has changed significantly, as they are moving to the “Cloud”. Already many of ForgeRock customers are deploying OpenDJ servers on Amazon or MS Azure, and the requirements for data confidentiality are increasing, especially as the file system and disk management are no longer under their control. For that reason, we’ve recently introduced a new feature in OpenDJ, giving the ability to administrators to encrypt all or part of the directory data before writing to disk.clouddataprotection

The OpenDJ Data Confidentiality feature can be enabled on a per database backend basis to encrypt LDAP entries before being stored to disk. Optionally, indexes can also be protected, individually. An administrator may chose to protect all indexes, or only a few of them, those that contain data that should remain confidential, like cn (common name), sn (surname)… Additionally, the confidentiality of the replication logs can be enabled, and then it’s enabled for all changes of all database backends. Note that if data confidentiality is enabled on an equality index, this index can no longer be used for ordering, and thus for initial substring nor sorted requests.

Example of command to enable data confidentiality for the userRoot backend:

dsconfig set-backend-prop \
 -h opendj.example.com -p 4444 \
 -D "cn=Directory Manager" -w secret12 -n -X \
 --backend-name userRoot --set confidentiality-enabled:true

Data confidentiality is a dynamic feature, and can be enabled, disabled without stopping the server. When enabling on a backend, only the updated or created entries will be encrypted. If there is existing data that need confidentiality, it is better to export and reimport the data. With indexes data confidentiality, the behaviour is different. When changing the data confidentiality on an index, you must rebuild the index before it can be used with search requests.

Key Management - Photo adapted from https://www.flickr.com/people/ecossystems/

When enabling data confidentiality, you can select the cipher algorithm and the key length, and again this can be per database backend. The encryption key itself is generated on the server itself and securely distributed to all replicated servers through the replication of the Admin Backend (“cn=admin data”), and thus it’s never exposed to any administrator. Should a key get compromised, we provide a way to mark it so and generate a new key. Also, a backup of an encrypted database backend can be restored on any server with the same configuration, as long as the server still has its configuration and its Admin backend intact. Restoring such backend backup to fresh new server requires that it’s configured for replication first.

The Data Confidentiality feature can be tested with the OpenDJ nightly builds. It is also available to ForgeRock customers as part of our latest update of the ForgeRock Identity Platform.

New version of ForgeRock Identity Platform™

Ludo1 Comment

This week, we have announced the release of the new version of the ForgeRock Identity Platform, which brings new services in the following areas :

  • Continuous Security at Scale
  • Security for Internet of Things (IoT)
  • Enhanced Data Privacy Controls

FRPlatform

This is also the first identity management solution to fully implement the User-Managed Access (UMA) standard, making it possible for organizations to address expanding privacy regulations and establish trusted digital relationships. See the article that Eve Maler, VP of Innovation at ForgeRock and Chief UMAnitarian posted to explain UMA and what it can do for you.

A more in depth description of the new features of the ForgeRock Identity Platform has also been posted.

The ForgeRock Identity Platform is available for download now at https://www.forgerock.com/downloads/

In future posts, I will detail what is new in the Directory Services part, built on the OpenDJ project.

Rencontrez ForgeRock à SIdO Lyon, les 7 et 8 Avril

LudoLeave a comment

Salon Internet des ObjetsJe serai présent avec notre équipe au SIdO, l’événement 100% dédié à l’Internet des Objets qui aura lieu à Lyon les 7 et 8 Avril 2015.

Outre notre présence dans l’espace coworking pendant les 2 jours, Lasse Andresen, CTO de ForgeRock, animera un workshop avec ARM et Schneider sur la place de l’Identité dans l’Internet des Objets, le Mercredi 8 à 13h30.

N’hésitez pas à venir nous rendre visite dans l’espace coworking.

POODLE SSL Bug and OpenDJ

Ludo6 Comments

A new security issue hit the streets this week: the Poodle SSL bug. Immediately we’ve received a question on the OpenDJ mailing list on how to remediate from the vulnerability.
While the vulnerability is mostly triggered by the client, it’s also possible to prevent attack by disabling the use of SSLv3 all together on the server side. Beware that disabling SSLv3 might break old legacy client applications.

OpenDJ uses the SSL implementation provided by Java, and by default will allow use of all the TLS protocols supported by the JVM. You can restrict the set of protocols for the Java VM installed on the system using deployment.properties (on the Mac, using the Java Preferences Panel, in the Advanced Mode), or using environment properties at startup (-Ddeployment.security.SSLv3=false). I will let you search through the official Java documentations for the details.

But you can also control the protocols used by OpenDJ itself. If you want to do so, you will need to change settings in several places :

  • the LDAPS Connection Handler, since this is the one dealing with LDAP over SSL/TLS.
  • the LDAP Connection Handler, if the startTLS extended operation is to be used to negotiate SSL/TLS establishment on the LDAP connection.
  • the HTTP Connection Handler, if you have enabled it to activate the RESTful APIs
  • The Crypto Manager, whose settings are used by Replication and possibly the Pass Through Authentication Plugin.
  • The Administration Connector, which is also using LDAPS.

For example, to change the settings in the LDAPS Connection Handler, you would run the following command :

# dsconfig set-connection-handler-prop --handler-name "LDAPS Connection Handler" \
--add ssl-protocol:TLSv1 --add ssl-protocol:TLSv1.1 --add ssl-protocol:TLSv1.2 \
-h localhost -p 4444 -X -D "cn=Directory Manager" -w secret12 -n

Repeat for the LDAP Connection Handler and the HTTP Connection Handler.

For the crypto manager, use the following command:

# dsconfig set-crypto-manager-prop \
--add ssl-protocol:TLSv1 --add ssl-protocol:TLSv1.1 --add ssl-protocol:TLSv1.2 \
-h localhost -p 4444 -X -D "cn=Directory Manager" -w secret12 -n

And for the Administration Connector :

# dsconfig set-administration-connector-prop \
--add ssl-protocol:TLSv1 --add ssl-protocol:TLSv1.1 --add ssl-protocol:TLSv1.2 \
-h localhost -p 4444 -X -D "cn=Directory Manager" -w secret12 -n

All of these changes will take effect immediately, but they will only impact new connections established after the change.

New ForgeRock product available : OpenIG 3.0

LudoLeave a comment

Since the beginning of the year, I’ve taken an additional responsibility at ForgeRock: Product Management for a new product finally named ForgeRock Open Identity Gateway (built from the OpenIG open source project).

OpenIG is not really a new project, as it’s been an optional module of OpenAM for the last 2 years. But with a new engineering team based in Grenoble, we’ve taken the project on a new trajectory and made a full product out of it.

OpenIGOpenIG 3.0.0 was publicly released on August 11th and announced here and there. But as I was on holidays with the family, I had not written a blog post article about it.

So what is OpenIG and what’s new in the 3.0 release ?

OpenIG is a web and API access management solution that allows you to protect enterprise applications and APIs using open standards such as OAuth 2.0, OpenID Connect and SAMLv2.

Enhanced from the previous version are the Password Capture and Replay and SAMLv2 federation support features. But OpenIG 3.0 also brings several new features:

  • Support for OAuth 2.0 and OpenID Connect standard protocol to ease authentication and authorized access from clients, browsers, mobile devices and things
  • Support for scripting using the Groovy language to quickly develop complex flows
  • Support for protecting multiple applications or APIs with a single instance and splitting configuration in multiple dynamically reloaded files

I’ve presented publicly the new product and features this week through a Webinar. The recording is now available, and so is the deck of slides that I’ve used.

You can download OpenIG 3.0 from ForgeRock.com, or if you would like to preview the enhancements that we’ve already started for the 3.1 release, get a nightly build from ForgeRock.org.

Play with it and let us know how it is working for you, either by email, using a blog post or writing an article on our wiki. I will be reviewing them, relaying and advertising your work. And I’m also preparing a surprise for the authors of the most outstanding use cases !

I’m looking forward to hear from you.

Save the date for the 2014 ForgeRock Identity Relationship Management Summit

LudoLeave a comment

The date has been set, the 2014 ForgeRock summit in United States will take place on the week of June 2nd, in Phoenix AZ.

Make sure you block the date in your calendar ! I hope to see you there.

And if you’re in Europe, don’t panic ! We are also planning an EMEA summit in the fall. The date and location will be announced later.

Assigning a Custom Password policy to a subTree

Ludo4 Comments

OpenDJ supports defining password policies that are quite complete in term of security measures to reduce the risks associated with textual passwords. It also defines 2 default policies, one for the administrators such as “cn=Directory Manager”, and one for all other users : the “Default Password Policy”. But it is possible to define additional password policies and assign them to individual users or group of users. Today, we are considering how to assign a password policy to all users under a specific subtree. In the article below, I first define a new custom password policy and then I demonstrate 2 ways of assigning that password policy to all persons under the ou=people,dc=example,dc=com subtree.

Defining a custom password policy using dsconfig:

$ dsconfig create-password-policy \
 --set default-password-storage-scheme:Salted\ SHA-256 \
 --set password-attribute:userpassword \
 --type generic \
 --policy-name Custom\ PP \
 --hostname lpmac.local \
 --port 4444 \
 --bindDN cn=Directory\ Manager \
 --bindPassword ****** \
 -X -n

1- Assigning the password policy through a Virtual Attribute.

$ dsconfig create-virtual-attribute \
 --set attribute-type:ds-pwp-password-policy-dn \
 --set enabled:true \
 --set value:cn=Custom\ PP,cn=Password\ Policies,cn=config \
 --set base-dn:ou=people,dc=example,dc=com \
 --set filter:\(objectClass=person\) \
 --type user-defined \
 --name Custom\ PP\ Assignment \
 --hostname lpmac.local \
 --port 4444 \
 --bindDN cn=Directory\ Manager \
 --bindPassword ****** \
 -X -n

Check that the password policy is assigned properly:

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' '+' userPassword
dn: uid=user.1,ou=People,dc=example,dc=com
userPassword: {SSHA}u+52Ld6iaTvFoNlQvqTHrn1BBW9IjjT2/I25hg==
numSubordinates: 0
ds-pwp-password-policy-dn: cn=Custom PP,cn=Password Policies,cn=config
structuralObjectClass: inetOrgPerson
pwdPolicySubentry: cn=Custom PP,cn=Password Policies,cn=config
subschemaSubentry: cn=schema
hasSubordinates: false
entryDN: uid=user.1,ou=people,dc=example,dc=com
entryUUID: 4e9b7847-edcb-3791-b11b-7505f4a55af4

Change the user password, the new password should be encoded with the scheme specified (SSHA-256)

$ ldappasswordmodify -p 1389 -D uid=user.1,ou=People,dc=example,dc=com -w password -A -n newPassword
 The LDAP password modify operation was successful

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' userPassword
dn: uid=user.1,ou=People,dc=example,dc=com
userPassword: {SSHA256}vjIdZEtF1AIiM0EgY9unZUXXublwQwlOCoe4RYEIHtpzumW1hYyvNg==

2 – Assigning the password policy using Collective Attributes :

$ ldapmodify -D cn=directory\ manager -w secret12 -p 1389
dn: cn=Pwp for Users,dc=example,dc=com
changetype: add
objectclass: collectiveAttributeSubEntry
objectclass: extensibleObject
objectclass: subentry
objectclass: top
ds-pwp-password-policy-dn;collective: cn=Custom PP,cn=Password Policies,cn=config
subtreeSpecification: { base "ou=people", specificationFilter "(objectclass=person)"}

Processing ADD request for cn=Pwp for Users,dc=example,dc=com
ADD operation successful for DN cn=Pwp for Users,dc=example,dc=com

Now we can check that the password policy is well assigned, and that it’s used when changing password for example.

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' '+' userPassword
dn: uid=user.1,ou=People,dc=example,dc=com
userPassword: {SSHA}6tHBLHh2C25UpAsKX0eq0d6LEXYGX+Jcm4dh7g==
numSubordinates: 0
ds-pwp-password-policy-dn: cn=Custom PP,cn=Password Policies,cn=config
structuralObjectClass: inetOrgPerson
etag: 000000008211ac6a
pwdPolicySubentry: cn=Custom PP,cn=Password Policies,cn=config
subschemaSubentry: cn=schema
hasSubordinates: false
collectiveAttributeSubentries: cn=Pwp for Users,dc=example,dc=com
entryDN: uid=user.1,ou=people,dc=example,dc=com
entryUUID: 4e9b7847-edcb-3791-b11b-7505f4a55af4

$ ldappasswordmodify -p 1389 -D uid=user.1,ou=People,dc=example,dc=com -w password -A -n newPassword
 The LDAP password modify operation was successful

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' userPassword
 dn: uid=user.1,ou=People,dc=example,dc=com
 userPassword: {SSHA256}WswyH9ANoKcxQWlSn/eL8h/dNk532K/e5zGlJcwiwMLsCQqw+cAX0Q==

So which method to assign a password policy to specific users is best ?

The first method should be preferred when the password policy is defined in the configuration (as we’ve done in the example). Both configuration entries, the password policy and its assignment, are under the “cn=config” tree,  but need to be defined in all replicas.

The second method defines the assignment of a policy to users as an subentry collocated with the data, and will be replicated. It should be preferred if the password policy is also defined as a subEntry, along with its assignment. Such way of configuring a password policy is documented in the Administration Guide, Configuring Password Policies section, procedure 10.3 – To Create a Subentry Based Password Policy.

More secure passwords !

Ludo8 Comments

I’ve received an intriguing request from a customer last week :  he wanted to know if we’ve done benchmarks of the password hashing schemes that are available in OpenDJ, our LDAP directory service. Their fear was that with stronger schemes, they could not sustain a high authentication rate.

In light of the LinkedIn leak of several millions of passwords, hashed with a simple unsalted SHA1, I decided to run a quick and simple test.

SSHA1 is the default hashing scheme for password in OpenDJ. The salt is an 8 bytes (64-bit) random string and is used with the password to produce the 20 bytes message digest. But OpenDJ directory server supports a wide range of password hashing scheme and salted SHA512 is currently the most secure hashing algorithm we support (and the salt here is also an 8 bytes (64-bit) random octet string).

So for the test, I generated a sample directory data set with 10 000 users, and imported it in the OpenDJ directory (a 2.5 development build) with the default settings, on my laptop (MacBook Pro, 2.2 GHz intel Core i7).

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "dc=example,dc=com" 'uid=user.10' dn userPassword
dn: uid=user.10,ou=People,dc=example,dc=com
userPassword: {SSHA}cchzM+LrPCvbZdthOC8e62d4h7a4CfoNvl6d/w==

I then ran an “authrate” which is a small benchmark tool that allows to stress an LDAP server with a high number of authentications (LDAP Bind requests) and let it run to 5 minutes.

authrate -h localhost -p 1389 -g 'rand(0,10000)' -D "uid=user.%d,ou=people,dc=example,dc=com" -w password -c 32 -f
-----------------------------------------------------------------
 Throughput     Response Time
 (ops/second)   (milliseconds)
 recent average recent average 99.9% 99.99% 99.999% err/sec
 -----------------------------------------------------------------
 ...
 26558.0  26148.9   1.179    1.195  10.168  19.431  156.421      0.0

I then stopped the server, changed the import default password encryption scheme to Salted SHA512, and reimported the data.

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "dc=example,dc=com" 'uid=user.10' dn userPassword
 dn: uid=user.10,ou=People,dc=example,dc=com
 userPassword: {SSHA512}eTGiwtTM4niUKNkEBy/9t03UdbsyYTL1ZXhy6uFnw4X0T6Y9Zf5/dS7hDIdx3/UTlUQ/9JjNV9fOg2BkmVgBhWWu5WpWKPog

And then re-run the “authrate”

$ authrate -h localhost -p 1389 -g 'rand(0,10000)' -D "uid=user.,ou=people,dc=example,dc=com" -w password -c 32 -f
 -----------------------------------------------------------------
 Throughput     Response Time
 (ops/second)   (milliseconds)
 recent average recent average 99.9% 99.99% 99.999% err/sec
 -----------------------------------------------------------------
 ...
 25481.7 25377.6 1.222 1.227 10.470 15.473 158.234 0.0

As you can see, there is not much of a difference in throughput or response time, when using the strongest algorithm to hash user password. So do not hesitate to change the default settings and make use of the strongest password hashing schemes with OpenDJ. It could save you from the embarrassment of, one day, contacting each of your users or customers to ask them to change their compromised password.

The default password hashing schemes are in 2 locations :

  • The default password policy for all passwords that are changed online.
dn: cn=Default Password Policy,cn=Password Policies,cn=config
ds-cfg-default-password-storage-scheme: cn=Salted SHA-512,cn=Password Storage Schemes,cn=config
  • In the Import Password Policy
dn: cn=Password Policy Import,cn=Plugins,cn=config
ds-cfg-default-user-password-storage-scheme: cn=Salted SHA-512,cn=Password Storage Schemes,cn=config

Both properties can be changed with dsconfig while the OpenDJ server is running, and the new scheme will be used for all subsequent operations.

OpenAM 10.0.0 is now available…

LudoLeave a comment

This is a big milestone for ForgeRock and the OpenAM project, an open source WebSSO, Authentication, Authorization, Federation and Entitlements solution. After months of development (a few more than we anticipated), we’ve finally released OpenAM 10.0.0, a major version of the product.

OpenAM 10 brings a set of new features, including support for OAuth 2.0 client authentication, the ForgeRock Identity Gateway (built out of project OpenIG), enhanced SAML 2 identity provider capabilities, a new Risk Based Authentication module, …  It also now relies on OpenDJ 2.4.5, the latest stable release of OpenDJ the open source LDAP directory server, and supports the internet-draft based LDAP password policy. You can find more details  in the press announcement, or the product release notes. The documentation of the OpenAM 10 release can be read at http://docs.forgerock.org/en/index.html?product=openam&version=10.0.0.

The OpenAM 10 release owes a lot to the OpenAM community, for the issues raised : a total of 41 issues fixed in OpenAM 10 were raised by 26 different persons, and for the generous patches offered to fix over a dozen of these issues.
To each and every contributor : THANK YOU !

OpenAM universal gateway presentation at RMLL 2011

LudoLeave a comment

Last month, just before the French national day, I was in Strasbourg to participate in the RMLL.

Photo by Sebastien Bahloul

On the occasion, I did a presentation in the security track, about OpenAM Universal Gateway, another piece in the complex puzzle of Web Single Sign-On. The Universal Gateway solves an important problem in Access Management: allowing single sign-on for applications that are usually left out because they are based on legacy or non standard based technology.

The Universal Gateway comes from ApexIdentity, an acquisition that ForgeRock did in the spring. It’s been released in open source as part of the OpenAM source code repository.

The presentation I did was in French, and so are the slides.

You can find more about the Universal Gateway on ApexIdentity web site, and soon on OpenAM documentation.

Newbie help : How to reset the Directory Manager’s password ?

Ludo4 Comments

We get this question quite often on IRC or mailling lists, from newbies who’ve installed OpenDJ (or OpenDS) for evaluation and forgot the Directory Manager’s password.

So here are the steps :

Make sure OpenDJ is stopped.

bin/stop-ds

Generate an encoded password for Directory Manager :

bin/encode-password -s SSHA512 -c AS3cur3PassW0rd
Encoded Password:  "{SSHA512}G/knE0xkyW2Af3+1MFy+yPYxchGgLuqog71R4njPJcs9t5NDAadqLxU7pxZjZkrDquQeb5aq7tum1ZFC3uE+r4Nmuil4S46A"

Copy the string within quotes (without the quotes), and edit the config/config.ldif file.

Go down to the following entry

dn: cn=Directory Manager,cn=Root DNs,cn=config

Replace the value of userPassword with the newly generated one.

dn: cn=Directory Manager,cn=Root DNs,cn=config
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
objectClass: ds-cfg-root-dn-user
userpassword: {SSHA512}G/knE0xkyW2Af3+1MFy+yPYxchGgLuqog71R4njPJcs9t5NDAadqLxU7pxZjZkrDquQeb5aq7tum1ZFC3uE+r4Nmuil4S46A
...

You can now restart the server and administer it.

OpenDJ: Troubleshooting LDAP SSL connections

Ludo4 Comments

Troubleshooting Secure Socket Layer (SSL, also now standardized as TLS) issues is not trivial and there is no secret sauce specific to OpenDJ.

Should an LDAP SSL connection fails due to the server, you should find a descriptive error message in the server’s errors log (in logs/errors). But sometime the connection is aborted by the client with some obscure message. Often we see a message ending with ” javax.net.ssl.SSLHandshakeException: no cipher suites in common“.

Java has some debugging capabilities embedded and they are pretty easy to use with the OpenDJ LDAP directory server, which just need to be restarted with some additional arguments: -Djavax.net.debug=all or -Djavax.net.debug=ssl.

There are two ways to add extra arguments to the OpenDJ server startup command, using an environment variable, or using the java.properties file.

Using env variable

– you define the OPENDS_JAVA_ARGS environment variable. And you restart the server. If you do so, make sure you include all previous arguments.

OPENDS_JAVA_ARGS='-server -Xms1G -Xmx1G -Djavax.net.debug=ssl,handshake,trustmanager' bin/start-ds

Using the java.properties file

Edit the java.properties file in the config directory.
Since you probably only want to track the OpenDS directory server SSL access, you should append the -Djavax.net.debug=ssl,handshake,trustmanager args to the start-ds line (rather than applying it to all commands).

start-ds.java-args=-Xms1G -Xmx1G -server -Djavax.net.debug=ssl,handshake,trustmanager

Save the file and run the dsjavaproperties command:

bin/dsjavaproperties

Now restart the server, using the start-ds command

Where is the output ?

All SSL related logs are output in the logs/server.out file.
To test, you can use ldapsearch :

bin/ldapsearch -Z -X -p 1636 -b "" -s base '(objectclass=*)'

And if you look into the logs/server.out file, you will see something similar to this:

Using SSLEngineImpl.
 Allow unsafe renegotiation: false
 Allow legacy hello messages: true
 Is initial handshake: true
 Is secure renegotiation: false
 LDAP Request Handler 0 for connection handler LDAP Connection Handler 0.0.0.0 port 1636, READ: SSL v2, contentType = Handshake, translated length = 81
 *** ClientHello, TLSv1
 RandomCookie: GMT: 1287771875 bytes = { 68, 231, 5, 253, 105, 26, 137, 36, 38, 238, 12, 141, 110, 12, 59, 10, 192, 135, 113, 119, 108, 153, 10, 31, 127, 120, 110, 61 }
 Session ID: {}
 Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
 ...

This will help you to identify what part of the secure connection is failing and fix it.

Note that -Djavax.net.debug=ssl enables debug of the SSL connections, while -Djavax.net.debug=all enables full debugging including use of certificates, and more. You can also find more debug options by using -Djavax.net.debug=help.

 

LDAP Advanced Administration for Enterprises…

Ludo12 Comments

OpenDJ directory server has one default administrator that can manage all aspects of the server.

In an earlier post, I’ve described how to create multiple administrative accounts in OpenDJ, and in another one, I’ve talked about the Privilege system and how it can be used to tailor the administrative roles of each account.

In most enterprises, administrators are usually employees and therefore have their own entries and password. For auditing purpose, security processes require that a change or an administrative task on the directory be done as the true person and not the administrative account. But often there are multiple administrators, and they can change role frequently. So what is the best practice for granting employees some administrative privileges ?

An efficient and manageable way  is to create an Administrators’ group and grant the privileges to all members of that group. When an employee, is no longer administrator, simply remove him from the group and he will loose all privileges associated. Likewise, adding a new administrator is just adding a member in the group.

With OpenDJ, this can be done with 2 simple entries : a group and a privilege collective attribute subentry.

The Group :

dn: cn=Administrators,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
objectClass: top
description: LDAP Administrators Group
cn: Administrators
member: uid=ludo,ou=People,dc=example,dc=com
member: uid=Matt,ou=people,dc=example,dc=com

The Collective Attribute Subentry :

dn: cn=Administrators Privilege,dc=example,dc=com
objectClass: extensibleObject
objectClass: collectiveAttributeSubentry
objectClass: top
objectClass: subentry
cn: Administrators Privilege
ds-privilege-name;collective: config-read
ds-privilege-name;collective: config-write
ds-privilege-name;collective: ldif-export
ds-privilege-name;collective: modify-acl
ds-privilege-name;collective: password-reset
ds-privilege-name;collective: proxied-auth
subtreeSpecification: {base "ou=people", specificationFilter
  "(isMemberOf=cn=Administrators,ou=groups,dc=example,dc=com)" }

How does it work ?

Collective Attributes is a standard based LDAP functionality that allows to define attributes and value that are defined once and appear in all entries that match the subtreeSpecification. Collective Attributes are defined in RFC 3671. For those who are familiar with Sun Directory Server’s Class Of Service, Collective Attributes provide a similar function, but based on industry approved standard.

OpenDJ collective attributes feature supports a few extensions to facilitate their use.

First, the standard way to define a collective attribute is to define it in the schema with a “c–” prefix. With OpenDJ, any existing attribute can be defined as collective with the ;collective attribute option.

Second, the scope of a Collective Attribute subentry as defined by the standard is a subtree, but the only filter possible is to specify the object class it applies to. We’ve extended the specificationFilter to accept an arbitrary LDAP filter, allowing a finer grained control of which entries are targeted.

In the example above, the filter is used to restrict the Privilege Collective Attribute subentry to apply only to entries that have the isMemberOf attribute with the value “cn=Administrators,ou=Groups,dc=example,dc=com”.

IsMemberOf is an operational read-only attribute (virtual) that is a back-link to the groups a user belongs to. OpenDJ does support the isMemberOf attribute for static groups, nested static groups and dynamic groups.

The subtreeSpecification also contains a base “ou=people” to restrict the targeted entries to the ou=people subtree. There are additional field allowed in the subtreeSpecification to indicate a depth in the tree for example.

As a result, collective attribute subentries, combined with groups, provide a flexible way to “inject” attributes and values to a specified set of entries, either to grant them specific privileges like in our example, or to decorate entries based on some common properties.

This said, remember that privileges are set in addition to the Access Controls. So giving a user the password-reset privilege for example, will be useless if there is no ACI allowing him or her to modify the userPassword attribute of other users. Granting access through an ACI to a group is as simple as using groupdn=”ldap:///cn=Administrators,dc=example,dc=com”;  to designate the authorized identities.