Novell Home

Cool Solutions

jjaimon

Contact jjaimon
Member since 9/5/2007

Bio

No author bio information

User Points

790 points earned on legacy (former) Cool Solutions site
0 points earned on this site

Author Archives

Nested Groups support in eDirectory 8.8 SP2

jjaimon

October 28, 2007 11:32 am

Reads: 7318

Comments:3

In my last blog, I talked about the performance improvements in eDirectory 8.8 SP2. I am going to talk about a couple of new features this time.

Configurable LDAP interfaces

A multi-valued string attribute is added to the LDAP server object. This attribute is used to store LDAP URLs on which LDAP server listens (on both cleartext and secure ports). This attribute is useful in configuring multiple instances, that requires each instance of the eDirectory server to listen on a specific interface. The attribute can be configured with the IP addresses and port numbers in the LDAP URL format. The LDAP server listens on these IP addresses and ports.

Examples:

The default value of ldapInterfaces attribute is ldap://:389 and ldaps://:636 This means, LDAP server listens on default ports on all the IP addresses configured in the machine.

Nested Groups

There have been multiple requests in the past to provide Nested Group support in eDirectory. We are there finally. eDirectory 8.8 SP2 comes with an experimental support for nested groups where groups can be member of another groups and rights can be assigned in a more organized way. I call it as experimental because the current implementation comes with its own limited support, such as:

  • Nested relationships do not span beyond the local server; the objects, users, and groups involved need to be locally present on the server.
  • No duplicate elimination is done in membership listing.
  • Nesting of dynamic groups is not supported.
  • Nested ACLs as well as the nesting semantics are not supported on older eDirectory servers (version 8.8 SP1 and earlier).Group nesting is possible only within the local server
  • Nested groups can be managed only through LDAP tools today. iManager plug-ins are awaited.

An existing static group can be promoted to a nested group by associating the nestedGroupAux auxiliary class. This auxiliary class should be present on both the containing group (groups that exhibit nested property) and the contained group (groups those are member of another group).

+read more

Are you ready for eDirectory 8.8 SP2?

jjaimon

July 27, 2007 6:50 am

Reads: 4967

Comments:17

I’m very excited about the forthcoming release of eDirectory viz., eDirectory 8.8 SP2. While the focus of eDirectory 8.8 was to provide features that help you create secure applications, support packs of this series concentrate more on the performance and scalability aspects.  eDirectory 8.8 came with features such as:

  • Encrypted attributes
  • Encrypted replication
  • Case sensitive Universal Password enforcement in the LDAP layer
  • Priority Sync feature
  • Authentication to eDirectory over SASL-GSSAPI
  • Security container caching for improved UP policy management

eDirectory has a unique capability of maintaining referential integrity among objects.  This has been enhanced in 8.8 SP1 by maintaining the references in a local server at the database layer using an indexed attribute, thus improving the performance.  We also shipped ldif2dib utility which helps  you upload millions of objects directly to the database which reduces the time to staging significantly. 

Here comes 8.8 SP2 with a super charged engine.  Performance reports that I’m seeing make me realize that this is the fastest directory engine we have had so far.  We made changes in almost all levels starting from low level OS interfaces to database, agent and protocol engines.  This report is not available for public distribution yet. However, to get an idea, have look at the following sample data taken on SLES10-SP1.

  • Overall 15% improvement over previous versions of eDirectory
  • 30% improvement in adding new user objects
  • 12% improvement in user bind.
  • Over 120% improvement in search performance on a 64bit SLES10-SP1 platform.

And that’s what I call engineering.  I’m waiting for this release. How about you?

 

+read more

Domain Services for Windows – Design Goals

jjaimon

July 16, 2007 12:47 pm

Reads: 5554

Comments:1

We looked at the overall use case of Domain Services for Windows in my last post.  Let’s have a look at the design goals of this product to get a clear understanding of the use cases.  The design goals listed below were carefully chosen.   

Design Goals

  • One of our main design goals was to provide seamless integration between windows and SuSE Linux Enterprise Server10 SP1 (SLES10-SP1). Windows administrators should be able to use Microsoft Management Console ( MMC ) for creating and managing users.  The same time, Novell administrators will be able to use Novell tools such as iManager to create or manage objects.  
  • Another design goal was to re-use existing open source components as much as possible.  However, there are some enhancements implemented in some components to get to get the complete functionality. For eg. MIT Kerberos with enhancements to support authorization data field used to contain user validation information or PAC, NTP with netlogon extensions etc.
  • Customers having windows and Novell network should be able to leverage the features of this product without re-creating their user identities.  So, it was essential to support existing eDirectory deployments  and have the same users log-on to both windows and SLES environments.

As you have noted already, seamless integration with Windows world, use of open source components and integration with existing Novell resources keeping eDirectory as the identity vault were the key design goals.

+read more

Domain Services for Windows

jjaimon

July 2, 2007 1:18 pm

Reads: 12282

Comments:21

Novell just released Open Enterprise Server Beta3. It included the first beta of Domain Services for Windows, the much talked about feature from Open Enterprise Server2. Domain Services for Windows received a lot of attention ever since it was demonstrated in the Brainshare this year.

Domain Services for Windows provides the ability to access both Novell Linux and Microsoft Windows services while leveraging the user store without multiple logins or object synchronization. Windows users can get away with the Novell client and still access Novell file and print services from Windows workstations seamlessly. In addition, administrator will be able to setup cross forest trusts between the existing Active Directory forest and Domain Services for windows. This will enable the Domain Services for windows users to access services from a pure Active Directory Forest. ( The reverse is not possible now )

With Novell Domain Services, the end user file and print activities will be identical, regardless of whether the user resides in eDirectory or AD, and the operating system that the file and print services reside on. This will help the user administrator to use the same tools to administer users and groups, irrespective of where the user resides.

The desired user experience for each of the roles is given below:

End Users can use the same default client operations from Windows XP or from Windows 2003 for mapping file system resources and getting access to print services.

  • Help Desk Agent will have the ability to use Microsoft Management Consoles to fully administer users and groups located in eDirectory or AD. Administrators can also use iManager or any legacy eDirectory tool to add users and groups.

Note: Windows administrators will not be able to use iManager or legacy tools to manage Microsoft specific attributes, policies, etc. They must use MMC for this.

  • Directory Administrator will have the ability to use the default vendor tool to administer shares, printers, policies and servers (MMC for AD repositories and group policies and iManager for eDir policies, printers, etc.)
  • Network Administrator will have the ability to install and configure using YaST for Linux and Default Windows install and configure tools for AD.

Use Cases

A typical heterogeneous network may look like the following diagram.

Aquila-approach2

The above deployment diagram has a real AD forest ( msforest.abc.com) and a forest configured with Domain Services for Windows. A replica ring of a configured domain can have Domain Services for Windows servers and supported eDirectory servers – eDirectory 8.8.x and 8.7.3. Administrators can manage the domain using iManger connected to any of these servers while, MMC connects to one of the Domain Services for Windows server. The same set of users can access resources from an Active Directory forest using the cross forest trust – a two way Kerberos based transitive trust between an Active Directory forest and Domain Services for Windows forest

+read more

RSS

© 2014 Novell