Scott’s Blog

I had just read an article about czechnology on somebody else’s blog today, when we experienced a wonderful improvised and somewhat hackish solution in our own environment. I have been working with Lyle from Longview systems on setting up a pilot of a network access control infrastructure that locks computers out of the network at the switch until they meet the virus scanner, malware scanner and Windows patch currency policy.

The system we are looking at is of course designed for a Windows Server / Active Directory environment, so it is not obvious getting it working with a Novell environment. With Windows desktops and servers, the NAC will do pass-through authentication, so when you boot up, you are on the untrusted network, you authenticate to AD via pass-through on the NAC server, the NAC agent runs and verifies you meet policy, then flips you onto the trusted network, at which point you run your login script and go to work. With NetWare / Open Enterprise Server, you can’t defer the login script, and if you allow enough traffic from the untrusted network to the trusted network to get users authenticated, they can also access data on the server, because authentication and data access via Novell core protocol uses the same ports. Allowing data access while the workstation is still in the untrusted network defeats the purpose of the NAC.

When Lyle and I were discussing the conundrum, Lyle mentioned that you can change the security configuration on the NAC server between the time the user logs in and the time the NAC agent starts to check your workstation for policy compliance. That led to the idea that we could allow the user access to eDirectory from the untrusted network before they login, so that the login could work and the login script could run. Then, when the user had logged in and all the drive mapping had been done, the NAC agent starts up and the NAC server revokes access to eDirectory and NCP protocol, effectively blocking the user from using the mapped drives. Then, after remediation, the workstation flips into the trusted network, and grabs a new IP address. The Novell client stays connected, and all those drive mappings suddenly work again. A nice clean but hackish solution!

This summer’s round of upgrades, patches and hardware replacement pretty much devastated my Novell Identity Manager configurations. Between changing single-node servers to two node clusters, SSL security patches that changed the certificate authorities, and standardization of eDirectory tree names, pretty much every IDM driver set needed to be touched to get it working again. I’ve just finished the last one, so our users should now have up-to-date synchronized data across all our connected systems.

I’ve got everything working on the IDM end of things for user synchronization into Deltek Vision. Now I just have to work with Bart to ensure that his java pieces pick up my output and do the right thing in Vision. I’ve configured the IDM driver between eDirectory and Active Directory to call java extension functions that output add, modify, rename and delete actions on eDirectory objects in our identity vault into files on disk. That part is all done. The java pieces we’re working on will pick up those files in order, and translate them into insert, update and delete sql calls into the SQL Server 2005 database we are using to host Vision on. We should be done tomorrow, because Bart is staying tonight to finish up the java pieces.

I’ve gotten the proof of concept working for pushing eDirectory user IDs into Deltek Vision (essentially a table in Microsoft SQL Server 2005) without using Novell’s Identity Manager Integration Module for Databases. As I wrote about before, we were confused about the licensing for the database integration module for Identity Manager 3, and when we found out what it would cost, we choked on it a bit. We decided to try to work with the Identity Manager components we already owned, namely eDirectory, Active Directory and GroupWise, and figure out a way to get credentials into Vision using one of those pieces.

We have a new Active Directory deployment that we just built, and we wanted to synchronize eDirectory credentials into it anyways, so we decided to start with that. Based on our past experience with Identity Manager, we realized it would be possible to intercept user adds and modifies on the subscriber channel between eDirectory and Active Directory. We can use data from those events kicked out of Identity Manager with custom java inside policies in the subscriber channel to populate the user table in SQL Server for Deltek Vision.

We were still running DirXML 1.1a in some of our sites, and we didn’t have Universal Password enabled in eDirectory. To get what we need working, we would have to upgrade to IDM3, and enable Universal Password. Fortunately, all our servers and eDirectory instances are at versions and patch levels sufficient to allow IDM3 to be installed and Universal Password to be enabled. I upgraded our enterprise tree yesterday to IDM3, and Universal Password, and started the process of updating the 10 DirXML drivers to IDM3 format with Password Synchronization 2.0. I also updated our corporate office production tree. I got the Universal Password synchronizing via the Distribution Password from our corporate office tree to our enterprise tree to our new IDM3 idvault tree, to Active Directory last night. I tested skimming off add and modify events and outputting them to files using java in the AD subscriber channel. That all works, so now our database administrator can take the data and stuff it into Vision’s SQL 2005 database.

I’ll finish the rest of the DirXML 1.1a to IDM 3 upgrades tonight, and by the weekend we should have all our credentials ready for synchronization into Vision.

I have been working on getting synchronization between eDirectory and SQL server working for our Deltek Vision rollout. I was under the mistaken impression that the jdbc driver for DirXML was included in the base product package. Yesterday I decided to activate our new IDM 3 server and I noticed that the jdbc driver didn’t activate when I installed the activation credential. I checked the licensing to find out that I was mistaken, and then checked the purchase prices for the Novell IDM 3 Integration Module for Database (the official name for the jdbc driver). I subsequently coughed up my skull over what seems like a very high list price of about $25,000 USD for the server instance, plus $6 US per user, plus maintenance. I checked the Sun Identity Manager product and confirmed that there is no licensing cost for their jdbc driver, and maintenance is optional. After a little thought it was not possible to justify an expenditure of over $30,000 plus maintenance just to get user synchronization to Deltek Vision.

I really didn’t want to have to manually manage users in Vision though. An initial bulk import would be easy enough, but ongoing maintenance of the users would be a pain in the backside. After discussing it with my boss and with our database / java programming expert Bart, we decided that the requirements of user synchronization for Vision were simple enough (User ID constructed from some attributes we keep in eDirectory plus the sha1 hashed password) that we could use some custom java classes within the subscriber channel between our Identity Manager identity vault and our AD domain controller to siphon off sufficient credential information to populate the user account table of Vision. Thus my last 10 days of work or so were reset and yesterday I started working on getting Active Directory synchronized with our eDirectory identity vault. Tonight I’m working late to get the universal password enabled on some of our offices so I can verify that we will be able to steal the password out of the eDirectory to Active Directory identity management datastream and hash it. So far everything is working as expected, and no need to buy the jdbc driver for IDM3, because the AD driver is included in the base price, so we already own it.

There’s nothing like a 90 degree direction change at the 11th hour.

We are in the final stretch before deploying our Deltek Vision setup. One of the outstanding items left is getting Novell Identity Manager setup to replicate eDirectory users into Vision as Vision login accounts. That way our users will be able to use their everyday login IDs in Vision.

Vision is built on Microsoft SQL Server 2005, and it stores it’s user accounts as rows in a SQL table. The passwords are stored as SHA1 hashes. We have a fair amount of experience with Identity Manager, because we use it to maintain a centralized enterprise-wide eDirectory with all our user credentials in it and we also use it to automatically provision our GroupWise accounts. We’ve never used it before though to synchronize user credentials with a database using the IDM JDBC driver, so this is a bit of a learning experience.

It took me a few days to get a grasp of how the Identity Manager driver for JDBC works, learn how to configure it and install JDBC drivers, learn how to work with SQL server (I have very little recent experience with SQL Server), and figure out how to get eDirectory to spit up clear passwords. We manage passwords in GroupWise, upon initial account creation, but we don’t synchronize passwords except between eDirectory instances, which is easy, so figuring out password synchronization was a bit of work.

Last night I had the “A-Ha!” moment and figured out how to get eDirectory to cough up passwords in the clear upon a password change, and now I have everything synchronizing over to our Vision SQL Server. The only thing left to do is to transform the output so that the clear text password is replaced with a SHA1 hash of itself, in lower case, before the data is stuffed into SQL Server 2005. Then it’s a matter of me working with Bart so he can write some triggers and stored procedures in SQL to take my data from eDirectory which I’m synchronizing to a transfer table, and inserting it into the proper Vision tables.

TUT361 IDM 3 and Provisioning - Beyond the Out-Of-The-Box Templates.

This is very disjointed because it is just a brain-dump written during the presentation and not edited at all.

The workflow pieces are similar to the transformation rules in DirXML. They are documents defined in XML and attached as attributes to entities in the eDirectory driver object for the workflow driver (the user application driver).

There are lots of templates in the IDM manager for creating workflows, that have predefined XML files. These can be used in wizards in iManager or in the Eclipse Designer tool. The iManager piece is the default tool, and it can be used to fill out the standard templates. If you want to go beyond the templates you need to dig in to the XML or use Designer.

You can manually edit the documents by grabbing them inside iManager and getting the into EMACS (insert your xml editor here). Then you are kind-of back into the DirXML (Identity Manager 1) world. Woohoo. That’s where I spent some time when we implemented our identity management stuff.

You can extend the schema with custom attributes, and use them in custom workflows, putting data widgets on the forms on the user application to access them. You can also show any data that is available in the directory abstration layer namespace. These attributes are shown inside the iManager tool. The schema used in the workspace is all in the namespace of the directory abstraction layer of the user application, not the namespace of eDirectory.

There is a function in the xml called flowdata, which allows you to pass your custom data along with the workflow, through the steps.

One limit of the tools, is that the iManager interface is only able to generate Entitlement-type workflows, because that’s all the templates do. For other types of workflows, you have to do custom workflows.

The workflow XML allows you to insert custom controls into the form elements to manage attributes in the directory, including any custom attributes you may have added to the schema.

Some of the tools shown in this demo were just released this week and are available on Cool Solutions.

In the xml, the Process element is the root of the process definition xml document. It is localizable. Form elements are the request and approval form data elements. They can contain data fields, display-labels, props (properties) and controls. Control types determine the display type of the data on the form. They consist of a whole bunch of visual types like text, linebreak, staticlist, datepicker, textarea, etc, depending what you want to display and what data you need to collect for your workflow. Each control can have an Editiable property which can be true or false. There is also the abiltiy to use a regular expression as a property that validates data input on the forms. The DN Display element shows data from the directory abstration layer, and a True False element is just a boolean selector element.

Data-item elements define which data-item elements are available in the workflow. You can hard-set them, or use flow-data.get functions or other functions, to obtain them from the work-flow process. You have to define a data-item in order to pass data from one phase of the workflow process to the next.

All processes have one or more start activities. Attriibutes of start activities are “audit” which can be off or on and forces auditing, and there is a timeout attribute that expires the workflow. Elements of the start activities are Notify, for email notifications, with all the settings you need to alert your auditor or process participants.

It really seems that what you would do is do a lot of your work in Designer, in the gui tool, and then when you get to tweaking, you would do that in a text editor.

I gotta get this working in Engineering.

IO163: Novell Identity Manager Overview and Futures

Key concept is that there is a main Identity Vault for Identity Manager. It doesn’t have to be authoritative for everything, but it conttains the whole identity for individuals, aggregated from whatever sources throughout your systems that are authoritative for each piece.

An example is if you have your HR system to be authoritative for most user attributes, but other place are authoritative for filesystem access, and maybe the email system is authoritative for email addresses. This is an example of “Role Based User Provisioning”, where an intial resource creation in one system kicks off an automated provisioning process that creates accounts on servers, dekstops, mail systems and enterprise applications.

The corollory of this is “Role Based De-Provisioning”, which means a single event should be able to kick off a workflow that ensures that access is quickly and completely revoked for departing staff members. We need work in this area, as we have been managing it with paper workflow, and it could be faster if we automated some of it.

IDM 3 was released in 12/2005, and in addition to having much improved configuration tools and tasks and an expanded list of datastore connector drivers, they have included a very amazing workflow tools that incorporate dynamic provisioning workflows for all kinds of iidentity requirements. It also incorporates a lot of features that enable identity regulatory compliance for organizations that have strong regulatory requirements.

Auditing is a key functionality. People who are responsible for resources are able to see exactly who has been given access to what.

We should look at IDM3 to auto-deploy Linux accounts on our gazillion Linux servers. Alternatively, get LDAP LUM integration working.

A new security feature is the ability to have encrypted attributes end-to-end. That includes encrypted data stored right inside the identity vault. Passwords, secrets etc. can be stored inside eDirectory in encrypted form for the use of IDM.

The presenter went through the workflow features again. This is pretty cool technology that we could really leverage. It occurs to me that you need strongly documented policies for corporate work processes if you want to implement this kind of workflow stuff. Detailed documentation would need to be developed and approved with the all the stakeholders prior to implementation. Once the documentation is produced, in general there is no actual programming required for most basic workflow operations.

The system also includes functionality of eguide, but also integrated with the workflow engine, plus email, instant messaging integration, and other advanced features.

Oops, out of laptotp power. Switching to dead-tree blogging. Should be updated later.

TUT273: Novell IDM 3 - Configuring the Workflow Based Provisioning System

This is part of the user application that runs as a J2EE war file on JBoss. It uses database tables to contain it’s data, and it supports the embedded MySQL database that comes with it, or SQL server or Oracle.

The user app includes search, list, org chart portlets, password self service, lightweight user admin, workfow, personalization and portal provisioning portlets. There is an eclipse plugin available on novell forge to manage this.

The main focus of the presentation was demonstrating a lot of the workflow features, but not a lot about setting up workflows. They described the functionalities of IDM3 workflow, including user requesting a provision, and then the whole approval process in the web application.

Then they went into iManager and went through the tasks of configuring a workflow. This is done using an IDM driver for the user application / workflow, that was very similar to any other IDM driver. It should be possible to use this in conjunction with a driver that can talk to SQL Server, to provide automatic provisioning of users from Deltek Vision, with approval and input from network administrators, and that kind of stuff. The iManager tools were very gui-ish and have the ability to let you set up groups for approval, so that anyone in the group can approve a given request for access, and you can setup additional data entry, like setting properties on the provisioning request in-process. You can make requests time-out, or escalate up the chain of command, or fancy stuff like that. It requires a lot of configuration of your actual identity store data, like manager heirarchy and stuff like that if you want it to work.

All in all, it looks like we could implement the hire/fire/cleanup of users with this much more easily than in a custom application.

We need to try it out in Engineering like Ed suggested.

TUT269: Novell iChain Migration to Novell Access Gateway

There are two ways Access Manager will ship: As a Linux version or as a NetWare version. The Linux version can be installed on one machine, but the NetWare one will require two. The Linux one is based on SLES 9 SP3 and the NetWare one is NetWare 6.5 SP5.

There is a common management interface that lets you manage all pieces in one interface, and manage a bunch of them together with a common configuration set. The new one supports working behind a NAT firewall, rather than right on the gateway.

They talked about the data flow, which consists of a lot of little arrows labelled A, B, C and so on pointing in different directions between various multicoloured boxes. The highlight is that they built it so that it was componentized so they could use parts of it to validate web sites like iChain, and plugins to talk to java application server plugins to authenticate web applications, and to authenticate ssl-vpn users.

They showed some significantly complicated architectures with L4 switches, multiple access gateways, multiple firewalls, and all kinds of stuff that we don’t need. We can get by pretty much with a one-box gateway at each Internet gateway, like we do now with iChain. I expect the best way to go to the new version will be to build a new one in the local gatway site, on new hardware, then convert the other one to a second one in the other gateway site.

The proxy server component stores the protected resrouce configurations, in xml files one per publicly accessible server. The identity server machine stores the roles and policies for authorization, formfill, and identity injection (formerly called OLAC).

Migration considerations:

The user experience should be the same. The migration probably has to be done over a period of time. Hardware requirements are still being determined and a white paper for hardwaqre sizing will be available later. On linux, the Access Gateway supports multiple CPUs and takes advantage of them for performance. It doesn’t support SLES9-64, only 32-bit.

There are a lot of new features in it that support very large installations, but we probably won’t use most of the high availability server pieces.