Configuring Intranet Security Within Ektron’s CMS, Part 1

By Ken McAndrew, Senior Technology Consultant View Comments

Configuring Intranet Security Within Ektron’s CMS, Part 1

When developing an intranet, one of the items to consider straight out of the gate is security. A content management system will help you get started, but there are still a number of things to think about. This two-part blog series will explore how to securely configure user setup with an intranet powered by Ektron™.

Understanding Ektron Users: Who Holds the Keys?

As of version 9.0, Ektron is divided between two user pools based on functional group. The first group is CMS authors, who have access to the Ektron workarea, PageBuilder configuration, and content. The second group is membership users, who have no back-end access, but have options for personalization.Ektron User GroupsHow many or few of the features you use for each group is up to you, but when choosing your user base for intranet access (that is, the front-end system people will browse daily) you need to consider three main things:


  1. Front-End Access
    If you’re planning to use PageBuilder on your site, you want all of your front-end access to come from the membership user base. This is easy to understand: you don’t want users, when they are just browsing (and especially if that is all they can do) seeing the PageBuilder function bar. Also, when they’re logged into the CMS itself, more JQuery libraries and stylesheets are loaded than are in just “browse” mode, so why burden the user more?


  2. Authentication Schemes
    Second, and potentially more confusing, is the choice between Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) in your authentication schemes. LDAP, besides presenting the caveat of being able to bring in users and not user groups, only allows users to be hooked up to the CMS authors side of the fence. AD allows you to hook in to either membership users or CMS authors, and you can get the groups from AD.

    What I would suggest is if you have AD, connect to the membership users so that your end users (of which you will likely have many more of than authors) will have full connectivity of their network passwords to their accounts. You can also import groups for permissions.

    On the other hand, if you only have LDAP, I would consider leaving it off as far as the Ektron workarea is concerned. More than likely you will want your end users to keep the same usernames as their network names, although the passwords will not match their network ones. But if you integrate LDAP, those usernames essentially become “reserved” by Ektron since you cannot use the same username twice.
    Ektron Authentication Schemes



  3. Mixed-Mode Authentication
    A final decision you have to make is if you have the need for “mixed-mode” authentication. For example, say you’re using Active Directory to authenticate users as membership users, but one of the requirements states that users might come from outside of AD. Ektron will not allow you to create users manually if you have AD hooked up. You can create users as CMS authors, but that exposes more permissions and access than you might want, and going the other way could expose the PageBuilder bar to people who don’t need to see it.

Lessons Learned

If you’re going to use network authentication, favor Active Directory over LDAP. Using AD allows you to connect directly to the membership users without a workaround login, and passwords will be handled by the network system as well. Create any CMS authors manually, as you will likely have far fewer in that group anyway.

If you are going to need “mixed-mode” membership users, however, you will not be able to use AD either. In this case, you can still maintain your regular usernames in the membership area for ease of use.

In part two, we’ll take a deeper dive into intranet authentication methodologies.

View our other posts on Ektron and Intranets.


Posted in: IT Security, Web Design & Development, Intranets