Archive for the ‘Best Practices’ Category

« Older Entries

Novell IDM Best Practices: Don’t Forget the Small Stuff

Monday, October 17th, 2011

Don’t Forget the Small Stuff

When developing a Novell IDM driver its easy to get focused on requirements and lose track of the little things that can come back to bite you later on. The perfect example of this is the DirXML-Associations attribute.

This handy little attribute is typically automatically set by a driver to establish a relationship between an object in eDirectory and the object in the driver’s connected system.  When this value is set for a specific driver it allows future changes to be processed more quickly and efficiently.  These relationships are stored in eDirectory on the object and consist of the unique identifiers from the connected systems; for example, the Microsoft Active Directory driver leverages the Active Directory’s GUID value for the account to create the association in eDirectory.

The problem is that once these associations are created there are only two ways of getting rid of them.  The most obvious way is to delete the associated object in eDirectory.  If the object holding the values is deleted then it goes without saying that the values are deleted.  This method doesn’t require any additional coding or consideration in the driver.

The other method is to remove the association value from the attribute in eDirectory either manually (not recommended) or programmatically by creating a policy in the driver that contains the Remove Association action.  This means that someone has to create a policy or policies that contain a number of conditions to determine if/when an association should be removed.  The only thing is that in the course of requirements gathering and design these use cases and conditions are overlooked and not documented and therefore do not get implemented.

More often than not requirements simply dictate that a driver is not to delete objects out of eDirectory.  The natural instinct is to create a simple policy that checks to see if the current transaction is a delete event and if so to do a simple veto action.  The veto action will stop the transaction from processing through the driver to eDirectory and will result in the eDirectory object being unchanged, including the driver association.

So what’s the issue with keeping a driver association in eDirectory after the object/account/record has been deleted out of the connected system?  Well, simply put, it causes errors! This is because of how the driver detects and uses the association values in the DirXML-Associations attributes for more efficient transaction processing its a problem to have an association for a driver that points to a nonexistent record.

The result is that when an transaction for an object in eDirectory in such a state processes through the associated driver the driver will use the invalid association as its target reference.  This causes the transaction to result in an error because the target reference no longer exists.  The obvious result of this is that no changes are made in the target system.

On the flip side of things, if an unassociated object/account is created/modified in the target system and the driver attempts determines that the record in questions matches are previously associated eDirectory record the driver will attempt to merge the records and create a new association in eDirectory with the new account.  This causes an issue too.  An eDirectory object is only allowed to have one association per driver and since the driver already has an association for the old record on the eDirectory object the merge process will fail and the driver logs will record an error along the lines of “Object already associated“.

In either case the obsolete associations in eDirectory essentially defeat the purpose of having an identity management system.  Removing an association through driver policies is simple to do and can go a long way in developing a system that delivers reliable identity management capabilities between the various connected systems.  So the next time you are planning a driver or get a requirement that demonstrates the use case where the relationship between eDirectory and a connected system is being destroyed remember to clean up the association.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tags: , , , , , , , , ,
Posted in Best Practices, Identity Management, Novell, Novell Identity Manager | No Comments »

Dealing with Mistakes in the Workplace

Thursday, September 29th, 2011

Unfortunately, as we all do, I recently realized in quite dramatic fashion, that I had made a mistake, a dumb call, a bad move to a group of folks that I would consider business partners and just as important, friends.  I am sure you have been there at some point yourself.  That moment that you realized you screwed up royally, your heart pounding, the sweat starting to show.  You holding out for a Reboot switch that you know won’t and can’t happen.  Unfortunately an apology probably won’t cut it in the scenario as much as you’d want to be able to apologize.

Try as you might you may have taken the wrong path and denied responsibility knowing this was the wrong way to handle it or taken the right path and admitted to the mistake.  Either way, in the end, you end up, more than likely deservingly, on the @#$% end of the stick.

So now is the time to remember we all learn from experience.  We all do dumb things, some dumber than others, but in the end mistakes are an inevitable part of life and if you don’t view them positively you will never learn and are doomed to repeat your mistakes.

As I reflected on my mistake I made a mental note of what not to do next time and to never put this one out of my mind so that I don’t do it ever again.  Ignorance may equal bliss but it will be short lived if you do it again as a result.

So dear readers, let me know what you have done to overcome a mistake and make it a positive.  You can sound off below (anonymously if you wish).

Tags:
Posted in Best Practices | 2 Comments »

Writing Policy in an XACML World

Wednesday, September 21st, 2011

There is a lot of chatter going on right now in trying to figure out who will be responsible to write those nagging IF, THEN, ELSE statements that will be the norm in the XACML implementations around the world.  So who should write the policies to begin with?  That is a question I think needs to be broken down into a few components before it can be answered.

1)      Education – How do I write XACML policy to begin with?  That will depend on version but the sake of this blog entry I plan to stick with XACML 3.0.

2)      Role – Does the organization view the business or IT side of the house as the responsible party and more importantly, should they? 

3)      Technology – This is a question of whether we put the proverbial cart before the horse.  The question being what role the XACML coders themselves will have in the policy implementation?  Also, what technology are we using to write the policies, translate them and implement them?

Education

The IF statement is simple in that we wish to define the attributes and their associated values that will let me get to the THEN statement?  IF the user is located in RENO and has a title of SVP or IT Manager THEN…

Within XACML 3.0 we start off with the concept of Permit or Deny and add in to the mix Obligations and Comments.  Basically, what authorized actions can I take post-authentication (typically), what am I allowed to do (permitted or denied) and are there any hoops I have to jump through in addition to simply a Permit/Deny scenario.  This bit of confusion being the THEN statement.

ELSE should be self-explanatory but I will sum it up as follows, “If all else fails, do the following”.

You may be asking yourself why I bothered to write the above.  I did so because the folks writing policy may be doing so in MS Word or Excel.  So let’s segue into our Role conversation.

Role

This is the bigger question surrounding policy.  Should the business write the policies?  Should the IT group write the policies? Should the lawyers write the policies?  There is no simple answer but I can make a few suggestions I have found reasonable with previous customers. 

1)      If you have an IT or Business Governance group, they should be on the hook for policy.  In lieu of Governance, IT Security is a great place to start.

2)      Within Governance or Security, an SME is always welcome, followed by an IT Architect.  This has to be weighed with Functional vs. Technical.  I have met many IT Architects in my day and they fall into two buckets.  The Technical Architect is the person you want defining ports and protocols, services and well, technology.  The Functional Architect is the person who can and usually does, double as an Analyst.  A guiding force as it were along the lines of an SME.  The Functional Architect is the person you want meeting with your business and IT teams and pulling out the policies one tooth at a time.

3)      Once Policy has been built, and I truly mean built, through questionnaires, meetings and workshops, it needs to go to the business and IT teams for review and approval.

4)      Post approval I recommend a legal review and possibly a Governance review.  Make sure no HIPAA, SOX, FERC, etc. regulations have been violated and that proper Separation of Duties (SOD) exists.

Technology

So how are our Functional Architects supposed to deliver policies to the “Policy Administrators” that will implement them?  This really depends on the strength of your education to the business and IT units and the delivery your SME/Function Architect/Analyst is most comfortable with.  My own preference is to use a basic tool that will allow an easy understanding when presented to Auditors, Lawyers, and the Business.  This can easily be Microsoft Word, Excel or Access (all of which can be saved in XML format).  The goal being that these policies will need to be converted to XACML policies in either an editor or vendor application.  The policy administrators must be keepers of code from a create/change/remove perspective so that we have a built in checks and balance approach to Policy validation.  Whatever you do, stop before you write a line a code and determine if the steps outlined in the Role discussion above have been fulfilled.  The biggest mistake we make is implementing technology before we have defined what we are trying to implement in the first place.  Never code side by side while you are writing requirements.  There is an order to things that if followed results in less wasted work.

So whether you are deciding to bring in a vendor or go it alone in the XACML, ABAC, PBAC spaces just remember Policy is what you make it and if you plan it out effectively then there will be less roadblocks that lead you to project failure.

Looking for a PBAC, XACML and/or ABAC SME, Functional Architect, Analyst or Implementor?  Feel free to reach out to the IDMWorks ABAC team.

Tags: , , , , , , , , , , , , , ,
Posted in Attribute Based Access Control (ABAC), Best Practices, Policy Based Access Control (PBAC), XACML | No Comments »

The ABAC tie in to RBAC, RAdAC and SAML

Monday, September 19th, 2011

I was in a conversation recently in regards to Extensible Access Control Mark-up Language (XACML) and  Attribute Based Access Control’s (ABAC) role in Role Based Access Control (RBAC), Risk Adaptable Based Access Control (RAdAC) and Security Access Mark-up Language (SAML).  The question surrounded whether ABAC can or should replace the other Access Control models and/or the open standard languages.

The short answer is no, and well, kind of yes.

Let me expound upon my vagary if you will.

Role Based Access Control (RBAC)

To start with Role Based Access Control we should start with what works.   The RBAC tools on the market have an advantage of tying the Identity to a Role that can be used for high level access rights that don’t need to change all that often.  Aveksa, Sailpoint, Oracle Identity Analytics, etc. pride themselves on the ability to role mine your application stack and set the role to the associated entitlements.  This allows the organization to fulfill most security audits and allows for easy re-certification of said roles quarterly, bi-annually, annually or whatever the requirement states.  The failing, if you were to call it such, is that to change the entitlements typically becomes very intricate as the roles the organization has explodes.  This forces the governance model to keep roles shallow at best.

Where ABAC shines is by allowing a deeper, more fine-grained authorization model by using policy combined with attribute values in order to allow a level of authorization commensurate with the values presented.  To do this, ABAC essentially strips out the Identity and relies solely on those attribute values to make a decision.  This can extend an RBAC separation of duty (SOD) policy greatly and alleviate a lot of risk while making SOD decisions in real time.

So while “yes”, you can replace your RBAC vendor’s toolset with an ABAC solution the real question is why would you?  The tools work very well together and allow for a greater sum of their parts as opposed to their own private silos.  If I had my druthers within my customer sites I would have an Identity Provisioning system (to automate Identity creation and management) that ties into my RBAC vendor tool (to grant high-level entitlements and set automated recertification policy) that leverages my ABAC tool to authorize application access at a fine grained level (with perhaps an SSO tool to manage Authentication, which XACML/ABAC does not).

Risk Adaptive Based Access Control (RAdAC)

Ah RAdAC, the grand unknown!  RAdAC essentially is the process of taking information we know about the user, whether that is attributes, meta-data or some other method of taking a plethora (hopefully) of information, running said data into a risk engine algorithm and spitting out data to make a much more informed decision.  This is particularly important on highly classified systems.  In this case ABAC is a natural fit in conjunction with a RAdAC tool in which the RAdAC tool becomes the defacto decision engine with ABAC the data provider (potentially as this can be some data aggregator like a virtual directory) and the authorization enforcer.  ABAC vendors can enforce based on classifications (such as meta-tagging your data as “Secret”,  “Top Secret” and “Confidential”) and can run policy based on location or various credentials much in the same way a RAdAC system so you can replace but again the why comes into play here.  RAdAC vendor tools typically have a better risk engine to help you define the risk algorithms instead of having to determine the set, write the policy and hope it doesn’t change.  Once again ABAC plays nicely with the additional Access Control method.

Secure Access Mark-up Language (SAML)

This time let’s dissect Extensible Access Control Mark-up Language (XACML ) vs. SAML.  This really isn’t a “Vs.” situation.  SAML tends to be used in the Authentication side of the house with limits on how deep it can go into Authorization.  Try locking down individual attribute lines in a web based widget framework with SAML.  It isn’t going to happen, but that is OK.   The point to XACML when used in conjunction with SAML is that it can extend the security framework by providing a more robust Authorization framework (i.e. fine-grained).  So don’t throw away your Web SSO vendor integration yet.  Can you? Well, once again the answer is “yes”, but why would you?  Keep your infrastructure and expand.  ABAC should not be used as a rip and replace technology, it is a flexible architecture that can “add to” instead of “take away”.

Long story short, ABAC is the nice kid on the playground that plays by himself until someone walks up and asks him to play.  Then he plays well with others.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tags: , , , , , , , , , , , , ,
Posted in Access Management, Attribute Based Access Control (ABAC), Aveksa, Axiomatics, Best Practices, BiTKOO, Oracle Entitlements Server (OES), Oracle Identity Analytics, RAdAC, RBAC, Risk & Compliance, SAML, Single Sign On (SSO), XACML | No Comments »

The Pitfalls of Body Shopping

Thursday, September 1st, 2011

Being in the Identity Management services business, we get approached all the time by various body-shops looking to fill their clients IDM needs. A large percentage of these firms are looking to address their clients’ needs with cheap resources. When I say cheap, I mean typically less than a equivalent full time employee resource would get in this field.

The question is are they really addressing the clients’ needs by obtaining cheap resources versus spending a bit more money to obtain truly qualified resources? My observations are no, they really are not meeting up to the clients expectations. You may wonder how I can make such a statement, but time and again I see requests coming in for the same project after just a couple of months.

A few things could be happening here:
1. The resource is not qualified and is asked to leave
2. The resource recognizes that they are not qualified and leaves due to pressure
3. The resource leaves to obtain a better rate for their skills
4. The client may not have been truly ready to start the project and needs to do a reset

Regardless of the reason, the one being affected here is the client. When running a body-shop volume typically takes precedence over quality as does margin.

I don’t believe that all the companies that are contracting for resources are looking for the cheapest body, but more likely the best rate for qualified resources.  The real gray area in these circumstances is what does qualified resource mean? Unfortunately in some cases it means having the right buzzwords in a resume, in others, it means an individual that can pass a 5 or 10-minute interview with a non-technical manager.  The shame of it is that it can affect the rest of us through the inevitable loss of trust.

I have found that the typical complexities associated with Identity Management in general (and in a lot of other technical niches) require skilled and experienced resources to successfully accomplish a majority of the required tasks. Skilled resources have extensive experience, are high in demand, and can command a decent salary. This is where the rub is.  The old adage of “you get what you pay for” reigns supreme.  Can you really ask for a “junior” resource that has 10 years experience in the niche, an MS in Comp Sci, 20 years over all experience and can Architect, Manage and Implement the product stack?  The simple answer is, “No”, yet go speak with your average body shop recruiter and watch how often that comes up.

By stepping away from the body-shop approach, the end client has a lot to gain.

Case in point, your friendly neighborhood IDMWorks!   By having an actual Team of resources dedicated to our specific niche, in this case IDM, we have a few advantages that become aware very fast to our customers. 

1) Our team support each other the moment a need arises.  When one of our resources gets stuck they simply shine the internal Bat-Signal and everyone jumps in with their own experiences to jump the hurdle.

2) We have a repository and knowledge base that our employees have access to and contribute to. Why recreate the wheel or spend 2 days of Internet research? 

3) We have weekly calls by practice and discuss unique challenges and determine the best approach for resolution.  Your projects are our projects and these discussions allow us to forgo getting stuck on previously known issues.

Looking to save money initially?  You can go the body-shop approach but in the long run, your cost will likely be more. 

Pay a little more up front and you are more likely to recognize success the first time around.  This goes beyond us, IDMWorks, as a company and speaks to any non-commoditized sector.  Buy into a team and the talent first.

Feel free to reach out to us at IDMWorks and let us show you our team approach to your project.

Tags: , , , , , , ,
Posted in Best Practices | No Comments »

Your IAM Toolset: Tools for Manipulating Large Text Files

Wednesday, August 31st, 2011

The Problem

Large text files such as log files, LDIFs or XML files can be awkward and painful to manipulate unless you write PERL as your first language or only use UNIX and Notepad and Word Pad freeze with large files.

The Solution

If you prefer a Windows interface:

Text Pad ++, EmEditor and Ultra Edit are not bad for files under 1 Gig. I prefer JujuEdit or HiEditor but for huge files VIM is the option to use with a VI like interface. However, I tend to use these editors just to view the big files and not to edit them.  There are easier tools for this (unless it is a ‘quick find and replace’ operation).

If you prefer a UNIX/LINUX interface:

You can utilize Cygwin with a bash shell to move about on a Windows box.  Cygwin can be installed with VIM, most Unix editors, FTP, and can tar and gzip files for easy interchangeability between systems but to really work with the files on replacing or deleting lines the old favorites work really well when you don’t want to take the time to write the PERL and Regex scripts needed.  AWK, SED and GREP are the usual ways to modify and delete parts of files and with Cygwin they are available on Windows. They really are powerful line text editors that can move through most files in no time. Even if you are a PERL whiz they are worth a look for those small problems within PERL code that will tkae you longer to look for than the fix needed.

Have a tool we should profile and/or add to the blog? Feel free to sound off below or reach out to us at IDMWorks

Tags: , , , , , , , , , , ,
Posted in Best Practices, Tips & Tricks | 1 Comment »

Your IAM Toolset: the NVD Database

Monday, August 29th, 2011

Being in technical field it seems the TLAs (Three Letter Acronyms) and FLAs (Four Letter Acronyms) abound. But at times knowing about a few of them may provide key information we can all use to protect our customers.

Such is the case with the NVD (National Vulnerability Database). 

First off, the NVD is hosted on the NIST.gov site. This database contains information about software or programming that can either create or leave open vulnerabilities. For example, if you type IDM on the search bar, 57 entries come back.  These include vulnerabilities in IDM apps including Novell and Sun IdM (btw, I only picked these two as they are on the first set of returned entries). If you open one of these vulnerabilities the NVD has information on what causes it, what damages it could do and most improtantly, how to remediate it.

You can search by product or vendor name to narrow in on the entries that might be of concern. Some of the newer ones have just been reported and might not have a solution yet. Of course you can check with support at the company whose software has a concern.

So I’d recommend taking a few minutes to explore this database and the information that is availableand add this site to your IDM toolset.

Have a tool we should profile and/or add to the blog? Feel free to sound off below or reach out to us at IDMWorks.

Tags: , , , , ,
Posted in Access Management, Best Practices, Identity Management, Tips & Tricks | No Comments »

Common Sense Mobile Application Security

Thursday, August 11th, 2011

A recent survey of mobile applications showed a whopping 78% of users store their username in plain text and more than 10% store the associated password in plain text as well. Unfortunately there appears to be few if any standards for mobile applications and applicable sensitive security such as username and password. This is an issue that doesn’t just affect users personally but can be a critical security flaw at the corporate level as they too dole out unsecured smart phones.

So what are the risks?

The iPhone and Blackberry are typically known to be more secure (sorry Android lovers) but that security has been compromised by users that don’t adequately take advantage of it (such as when a user doesn’t code lock their phone only to have it stolen or hacked).

Some easy mitigation steps:

1)  Always use a password to protect your phone.  While phones are starting to allow more expressive or longer password combinations, typically the minimum is four numbers (which was hacked in 18 minutes at Black Hat last week).  On the plus side, most phones will lock after “X” number of tries by default so a user can’t simply apply a brute force hack.

2) Always lock the phone when not in use and set the phone to auto-lock after “X” number of minutes.

3) Use a separate username and password for any CRITICAL mobile application that you might access via your phone.  Many smart phones support this feature now to lock folders and individual applications as well.  Eventually a Single Sign-On method that makes sense will apply to smart phones but for now, play it safe.

4) Set up remote wipe or set up a threshold for incorrect attempts to access before wiping.  This way you may just save yourself from a yet to be created app that can by-pass the current smart phone security.

This may seem like common sense security to most but if you aren’t in the Info Sec side of the house you probably haven’t given it much thought.

 Feel free to reach out to us at IDMWorks.

Tags: , , , ,
Posted in Apple, Best Practices, User IDs | No Comments »

PII & NIST, two great tastes that go great together!

Thursday, August 4th, 2011

Protecting Personally Identifiable Information (PII) is an issue that continues to grow in importance for individuals, companies big and small, multi-national corporations and governments. .  PII is defined as ‘information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc’.

It is in the news often (and it seems daily lately), as you can see from a few headlines I pulled through a quick search of breaches that occurred this week:

  • Massive Data Breach in South Korean Portal Effects 35 Million Users
  • EMC Foots a $66 Million Bill for RSA Attack
  • UNLV Admits a Possible 2008 Security Breach

The National Institute of Standards & Technology’s (NIST) take on it

In regards to these seemingly daily breaches there is a newly proposed NIST set of standards for Security and Privacy which is due to be published as Appendix J: Security and Privacy Controls for Federal Information Systems and Organizations in the NIST Special Publication 800-5 document in December, 2011.  It is of great curiosity how the government is tackling this sticky problem. Since the Appendix has its own review cycle separate from the review of the entire document one can surmise that the government is taking it very seriously.

So what is covered in this Appendix and can we apply it to the issues facing the Private Sector as well as the Public Sector?

The NIST approach is risk based. Identifying and managing risk factors in PII information is crucial. First, examining the existing data for PII criteria is suggested all the way down to the data fields themselves. This is data that is directly under an organizations control and would also be utilized by contractors or may be stored and available in a virtual environment.  There are two types of data defined, ‘Linked Data’ and ‘Linkable Data.’

Linked Data is data already associated with other PII where Linkable Data (currently “unlinked”) can conceivably be linked together to form information to find a specific individual.  PII data is not all equal either and as such it should be rated on a defined ‘PII confidentiality impact level.’   This level is determined by the amount of harm that could result from an information breach.  The rating levels are suggested as low (limited adverse effect), medium (serious adverse effect) and high (severe or catastrophic adverse effect).  At issue in the document is that a combination (‘linked data’) of lower rated pieces of information can cause a serious high breach such as ‘mother’s maiden name, place of birth and birth-date.’  In most states these three pieces of information supplied will get you a birth certificate.  Thus  information marked as low if combined correctly can be a much higher risk and might signify a higher rating. When determining PII impact level this of critical importance to keep in mind.

The NIST document also provides recommendations on how much PII should be collected by an organization or agency. Carefully making sure that redundant information and non-essential information is not collected and stored also reduces the amount of risk that is being taken on. For example, if you have already collected the email address can it be verified and referred to instead of collected again?

Reviewing how long PII retention is necessary also takes on important levels of risk so it is highly recommended to regularly determine what can be purged from the system.  Literally, put this on your schedule and make it a repeated activity!

Also extremely important is Access Control: Who has access? Do they need it and for how long? In most cases the math is simple, the less people with access to PII, the less risk there is.  If employees need access only to certain data for a project, give them limited access and an end date instead of the ‘keys to the kingdom.’  This is a good time to mention governance and training.  Comprehensive policies for handling PII and utilizing that to train employees to utilize and handle the data correctly with as little risk of exposure as possible also lessens the concerns that a ‘mistake’ or other incident will happen.

These follow the common areas:

  • Access Control
  • Separation of Duties (SOD)
  • Least Privilege
  • Remote Access
  • Auditable Events, Monitoring and Reporting

Basically how do we minimize risk to our customers, organizations, etc and still are able to get the job done well.

The Appendix also discusses minimizing PII information in another way that is important in organizations large and small.  Instead of using complete data for environments other than ‘Production,’ strip the data or ‘sanitize’ it for use.  Remove any fields that will identify the person referred in the object as much as possible.  This means removing PII data and still be able to develop and test with valid ‘production-like’ data sets.

Lastly, the document recommends having a plan for when a breach happens, not if it happens.  The plan should include initial notification of responsible and concerned parties, assessing the possible impact to the company and individuals and how to handle different scenarios that might occur.  The time to plan is in advance, not in the moment. Things that seem basic can sometimes get overlooked during a crisis unless it is documented with a checklist and test driven in advance.

In summation, the NIST document is for use as a guideline outside of the Government and at times inside. Your mileage may vary depending upon the regulatory laws that govern your business or organization and even your country.

Looking for additional insight into how PII affects your organization?  Feel free to reach out to us at IDMWorks.

Tags: , , , , , , , , , , , ,
Posted in Best Practices, NIST, Personally Identifiable Information (PII), Security & Risk, Standards | No Comments »

Novell IdM – Implementing Remote Loader on Microsoft Windows

Tuesday, August 2nd, 2011

When implementing Novell’s (or NETIQs) Identity Manager product there are times when a certain connector(s) must be run on the MS Windows platform. If Meta-Directory Engine is running on a Linux (or other non-Windows) platform the requirement is the use of the Remote Loader. When asked if it is better to run the Remote Loader on a Windows Domain Controller or simply on a Windows Member Server, the answer is to run it on a Member Server for several reasons:

  1. Most organizations maintain a very controlled environment particularly when it comes to what is installed on Domain Controllers.  Most organizations will not allow a service such as the Remote Loader (RL) to run on said Domain Controllers.  As a result it is generally required, due to policy, to run the Remote Loader on a Member Server.  
  2. Additionally, through experience, we have found over the years that due to patching and security controls that take place specific to Domain Controllers it becomes more efficient, in terms of over-arching stability, to run the RL on a Member Server.  
  3. Lastly, the separation of duties between the Active Directory team and the Identity Management team generally makes life easier to manage the RL if it is running on a Member Server (i.e. less political).

Another advantage of running the RL on a Member Server is the ability to run the RL in a clustered environment. Member Servers may be configured in a Microsoft cluster with instrumental registry keys for password synchronization configured as a clustered resource.  This will allow the Domain Controllers to communicate with the clustered resource for password synchronization to the Identity Vault and it will allow the Identity Vault to do the same.  This is a configuration that is supported by both Novell and Microsoft and is considered to be the best way to provide password synchronization failover.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tags: , , , , , , ,
Posted in Best Practices, Novell, Novell Identity Manager | No Comments »

« Older Entries