Saturday, 9 July 2011

Open Source Directory benchmark – part two

Open Source Directory benchmark – part two

This is the final part of a two part blog entry about an open source directory benchmark we performed. Please find the first part here. In this second part, we focus on the results of our benchmark.

After testing with our own custom developed tool for several hours we came to the results below, which are the average of 20 testruns. Our final report (available on request) contains more information about how the individual benchmarks were performed and how the directory servers were tuned for performance.

Search

We started by testing the amount of search operations a directory server can perform per second. As directory servers should be very fast in search operations, we expected these results would be high.

The fastest searches were performed on OpenDJ, previously known as OpenDS. OpenLDAP is a close second and as third we have Oracle Internet Directory. All servers perform very high on search operations. No surprise there, because this is the very reason for which directory servers exist.

Authentication

After testing how well these directory servers handle search requests, we wanted to know how fast they could handle authentication. We had to take care, however, not to flood the server with too many connections because that would render it irresponsive.

From the results, we can see that the commercial products (OID and AD) score better than the open-source variants. However, Fedora389 is very close to the same results. We have noticed that using our tool, we sometimes accidentally perform a successful denial-of-service attack on the directory servers. The former statement does not apply to the Oracle Internet Directory and Active Directory. We retested multiple times to get stable results.

Registration

Most Directory Server implementations are optimized for reading, so we expected some interesting results from the registration benchmark.

The registration benchmark results show that there are 2 directory servers which are clearly faster than the others: Fedora389 appears to be slightly faster than OpenDJ, but we feel this difference is negligible. These two servers are most capable of writing entries to disk or memory.

Modification

Modification is actually a sequential process that consists of:

  1. looking up the entry (reading)
  2. modifying it,
  3. and updating the directory server

This is a heavy resource process, so our expectations for these results were quite low.

Generally, the average modification speed is very low. OpenDJ scores best with 155 modifications per second. ApacheDS is second with 147 modifications per second, and then we have Fedora389 with 128 modifications per second.

Hardware performance impact

Every test was performed on the two hardware configurations as described earlier. The following graph indicates the average performance improvement per directory server when tested on the High End server compared to the Mid End server.

Conclusions

The following table lists the best peforming directory server of our benchmark per operation:

Operation

Best performing LDAP server

Search

OpenDJ

Authentication

Oracle Internet Directory

Registration

Fedora389

Modification

OpenDJ

We conclude that the performance of open source directory servers is comparable to that of Active Directory or Oracle Internet Directory for performing the benchmarked operations on relatively modest hardware.

Outro

While performing these benchmarks we have gained a lot of experience regarding configuring and tuning these directory servers. Many enterprises rely on directory server technology and it has been a rewarding experience for us showing that there are also open-source software packages that are up to the task.

Saturday, 2 July 2011

Open Source Directory benchmark – part one

Open Source Directory benchmark – part one

Directory servers are critical IT infrastructure components in many enterprise environments. Although many whitepapers about the performance of commercial directory servers and even benchmark tests are to be found online, no real comparison of their open source counterparts exists.

As interns, we recently completed an assignment to benchmark read, write, modify and authentication performance of different Directory servers. This two part blog entry reports on our findings. This first part introduces the directory servers we subjected to our benchmark. The second part contains the benchmark results and conclusions.

OpenLDAP

OpenLDAP is one of the more popular open source directory servers. OpenLDAP is one of the few directory servers that aren’t java based. The version used in our benchmark tests was: 2.4.25.

ApacheDS

ApacheDS is a Java based open source directory server. The server's networking code, MINA (Multipurpose Infrastructure for Network Applications) was designed for pluggable protocol providers of all sorts and not just LDAP. MINA should enable ApacheDS to handle large amounts of concurrency. The version used in our benchmark tests was: 1.5.7.

Fedora389

Fedora389 is a C based open source directory server. Fedora389 is the directory server developed by the same team as the Red Hat Linux distribution, and is a derivation from the original University of Michigan slapd project. The community of the project writes that Fedora389 is able to support enterprises in their directory needs. The version used in our benchmark tests was: 1.1.

OpenDJ

OpenDJ is a java based open source directory server. It is to be expected that this server will have some latency on throughput because it runs in a virtualized environment. This server is easy to configure. OpenDJ is a fork of the Sun Microsystems initiated OpenDS project. The version used in our benchmark tests was: 2.4.2.

Already half-way through our assignment, our sponsor realized that if he wanted to know if open source directory servers are able to compete with commercial of the shelf products, we had to put these products to the test on the same hardware.

Oracle Internet Directory

Oracle Internet Directory is a directory server that uses an Oracle database for storing the data. It uses LDAP v3 for handling operations on the directory server. In our test environment we used the Oracle 11g database, WebLogic 10.3.3, OFDM IDM 11.1.1.3 and java jdk-6u24-linux-x64 components. The version used in our benchmark tests was: 11G Release 2.

Active Directory

Active Directory is a directory server created by Microsoft. It supports LDAP and Kerberos-based authentication. Active Directory also serves as a central location for network administration and security. Active Directory stores all settings and information in a central database (JET). The version used in our benchmark tests was: Active Directory 2008 R2.

Hardware specifications

All directory servers were subjected to testing on two different – rather modest – hardware configurations. The main purpose of using two different configurations was to detect the performance impact of added RAM. The next two tables show the details of each hardware configuration:

Hardware configuration 1 (Mid End Server)

Model

Qosmio X300
PQX32E-028009BT

Processor

Intel(R) Core(TM)2 Extreme CPU Q9300 @ 2.53GHz

Memory

8GiB (2x 4GB 667MHz)

Network

RTL8111/8168B PCI Express Gigabit Ethernet controller 1GB/s

Storage

90GB Solid State Disk

Linux OS

CentOS 5.5 x64

Windows OS

Windows Server 2008 R2

Hardware configuration 2 (High End Server)

Model

Dell Precision M6500

Processor

Intel(R) Core(TM) i7 CPU X 940 @ 2.13GHz

Memory

16GiB (4x 4GB 1333MHz)

Network

NetXtreme BCM5761e Gigabit Ethernet PCIe 1GB/s

Storage

90GB Solid State Disk

Linux OS

CentOS 5.5 x64

Windows OS

Windows Server 2008 R2

Test client

At the start of our assignment, we started looking for a free tool to benchmark a directory server. When we found none we decided to write our own in C#.

Tuesday, 29 March 2011

IS4U @ InfoSecurity 2011

IS4U was present at the infosecurity.be event held at Brussels expo on the 23rd and 24th of March 2011.
For this years edition, IS4U teamed up with delITad to provide strong Identity & Access Management solutions in combination with delITad's Governance, Risk and Compliance advisory.

As it goes on the internet, the phrase "pictures or it didn't happen" seems to be quite well known, so...



Friday, 4 February 2011

Localizing a dropdown in FIM2010

While implementing Microsoft Forefront Identity Manager at our clients we encountered some difficulties with shaping the user interface to our needs and especially with providing a user-friendly experience for our users. We noticed that FIM 2010 still lacks advanced possibilities to customize the portal and that you have only a little amount of components at your disposal for shaping the portal. There is of course the FIM web service on which you can build your own portal, but we tried to get the most out of the build-in FIM Portal. We write this post to give an example of some of the problems we encountered, and to show how we solved them.

Our needs: Users must have the possibility to be part of multiple departments. We should be able to use the values of the department attribute as part of the displayName, description, etc. in FIM and AD. So our users must be able to select multiple departments and as an extra requirement, we wanted to show the department names according to the language setting of the browser.

Problems: While only thinking of the business logic, we thought ‘no problem’ and we started with implementing department as a multi-value attribute. No problems there. We could easily extract the values in our MA extensions to use them to create other values like ‘displayName’ or to put them in the description of a user ( “department1 – department2 - …”) . But then we started with creating the UI…

We didn’t like the UOCCommonMultivalueControl because we did not want the user to be able to enter free text. So our first choice was a multi-select dropdown. But after some research, it appeared that the UOCdropdown component only works with single valued attributes and that there isn’t a way to customize the build-in components like with Sharepoint - or .NET components.

As we thought to have found the perfect solution to our problem, we made a custom resource of ‘Department’. This custom resource would then be referenced by a person object, just like it is possible to reference someones manager. The UOCidentityPicker and the UOCListView offered the best user experience to choose between the large list of departments. Life was good ... until we hit another limitation: in FIM it isn’t possible to set a reference attribute in code. Dereferencing is possible in a custom workflow, but setting the reference attribute through code isn’t allowed. You can only do it from within the FIM Portal. So we were stuck…

But let us show how we eventually solved this problem.


Solution: it turned out that the users would be part of two departments at the most. So we created two department attributes each having their dropdown component. The only problem we now had left was the localization of the dropdown component. Like many of you would suggest, we tried to localize our dropdowns like Microsoft did with the ‘EmployeeType’ field. We created several constant specifiers and bound them to our department fields. But when you look at the example of the ‘EmployeeType’ field of Microsoft, you notice that they also specify the values in the regex or validation of the attribute itself. For ‘EmployeeType’ for example the regex was “^(Intern,Full-time Employee,Contractor)?$”. But while creating the regex for our department-dropdown ( “^(dep1,dep2,dep3,…)?$” ) we noticed the regex attribute can only obtain a max value of 256 characters. There had to be another way ...


When editing the Resource Control Display Configuration (RCDC) of the user object, you have a tab “Localization” at your disposal.



The key is that through this tab, it is possible to export/import an .xml file for each language. The exported .xml files are holding sets of “SymbolResourcePairs”. This is for example the way that FIM handles the translation of the grouping-captions in the different views.


Now, let’s take an example dropdown where the user can select her preferred language:

Step 1: Go to the RCDC for User Editing > Localization tab, and export the SymbolResourcePairs-xml file for each language.


Step 2: Adjust the xml files you just exported by adding new symbols to support the translation of a language dropdown.

For example:

- English

<Symbol ="nldCaption" ResourceString="Dutch"/>
<Symbol ="fraCaption" ResourceString="French"/>
<Symbol ="deuCaption" ResourceString="German"/>
<Symbol ="engCaption" ResourceString="English"/>
<Symbol ="otherCaption" ResourceString="Other"/>

- French

<Symbol ="nldCaption" ResourceString="Néerlandais"/>
<Symbol ="fraCaption" ResourceString="Français"/>
<Symbol ="deuCaption" ResourceString="Allemand"/>
<Symbol ="engCaption" ResourceString="Anglais"/>
<Symbol ="otherCaption" ResourceString="Autres"/>

Step 3: Now you can use the symbols you just created in the RCDC of User Editing.

In the xml file you can create a XmlDataSource based on these symbols. The value of the “Code“ tag will be the value that FIM saves in the attribute. The name tag references the symbols you created to show the caption in the right language.

<my:XmlDataSource my:Name ="languages">
<Languages>
<Language Code ="other" Name=" "/>
<Language Code ="nld" Name="%SYMBOL_nldCaption_END%"/>
<Language Code ="fra" Name="%SYMBOL_fraCaption_END%"/>
<Language Code ="deu" Name="%SYMBOL_deuCaption_END%"/>
<Language Code ="eng" Name="%SYMBOL_engCaption_END%"/>
</Languages>
</my:XmlDataSource>

As you can see, the xml references the symbols by adding “%SYMBOL_” and “_END%” to the name of the item.


Step 4: Now we can use the XmlDataSource in a UOCDropdown control.

The “ItemSource” property binds the control with the XmlDataSource we created. Properties “ValuePath” and “CaptionPath” references the right XML tags by using values “@Code” and “@Name”.


Step 5: Import all the adjusted .xml files. After you perform an IISRESET, change the default language value of your browser, and hit the refresh button. Now you will see a localized dropdown!

While implementing FIM, I learn a lot of these small, but handy features in FIM. I'll keep you posted whenever I find someting new.