Main Nav

Message from mike_shore@bcit.ca

Hi everyone,
 
We use SungardHE Ellucian Banner as our ERP, and AD as our authentication directory. We are moving towards a Microsoft-centric environment, with Exchange, Sharepoint and eventually Lync. We have hit a problem whereby some staff have multiple jobs (ie. part time instructor, as well as full time Payroll clerk). In these cases, Banner is able to track multiple jobs for a single person. However, AD only supports single values for attributes like Department, Job Title and Supervisor.
 
I realize there is no simple way to map multiple values in Banner down to a single value in AD. We have tried to determine what the person’s “primary” job is, based on hours committed to each job and other criteria. We have also considered using custom AD attributes to store additional information about an employee, but that info might not be visible to other AD-aware apps that are looking at specific attributes.
 
Another issue is workflow. If an employee’s manager needs to sign off on something, how does AD know which manager should be part of a particular workflow?
 
Are you in a similar situation? Have you managed to overcome this limitation and if so, what did you do and what kinds of compromises were required? We need to solve these issues before we travel too far down the Microsoft/AD path.
 
Mike Shore
Intermediate Systems Analyst
Business Application Services Team, IT Services
British Columbia Institute of Technology
3700 Willingdon Avenue, Burnaby, BC, V5G 3H2
 
Tel: 604-412-7474 · Fax: 604-439-6785
Email: mshore@bcit.ca · Web: www.bcit.ca/its
 
It's your career. Get it right.
"We are generally the better persuaded by the reasons we discover ourselves than by those given to us by others." - Blaise Pascal
P   Please consider the environment before printing this e-mail
 
 
 

Comments

Are you trying to tackle an access-management problem, and need to know if the person is in a particular role to access a given system ?  Or, are you tackling an attribute-update problem, where you might want the correct value(s) to appear for things such as a "department" attribute ?

Corey S.


On 05/29/2012 11:07 AM, Mike Shore wrote:
Hi everyone,
 
We use SungardHE Ellucian Banner as our ERP, and AD as our authentication directory. We are moving towards a Microsoft-centric environment, with Exchange, Sharepoint and eventually Lync. We have hit a problem whereby some staff have multiple jobs (ie. part time instructor, as well as full time Payroll clerk). In these cases, Banner is able to track multiple jobs for a single person. However, AD only supports single values for attributes like Department, Job Title and Supervisor.
 
I realize there is no simple way to map multiple values in Banner down to a single value in AD. We have tried to determine what the person’s “primary” job is, based on hours committed to each job and other criteria. We have also considered using custom AD attributes to store additional information about an employee, but that info might not be visible to other AD-aware apps that are looking at specific attributes.
 
Another issue is workflow. If an employee’s manager needs to sign off on something, how does AD know which manager should be part of a particular workflow?
 
Are you in a similar situation? Have you managed to overcome this limitation and if so, what did you do and what kinds of compromises were required? We need to solve these issues before we travel too far down the Microsoft/AD path.
 
Mike Shore
Intermediate Systems Analyst
Business Application Services Team, IT Services
British Columbia Institute of Technology
3700 Willingdon Avenue, Burnaby, BC, V5G 3H2
 
Tel: 604-412-7474 · Fax: 604-439-6785
Email: mshore@bcit.ca · Web: www.bcit.ca/its
 
It's your career. Get it right.
"We are generally the better persuaded by the reasons we discover ourselves than by those given to us by others." - Blaise Pascal
P   Please consider the environment before printing this e-mail
 
 
 

Corey Scholefield
Team Lead, Identity & Access Mgmt. Services
UVic Online | University Systems
University of Victoria | Victoria, BC, Canada
coreys@uvic.ca | +1.250.472.4549

Hi Mike,
    This is a common integration challenge with limited schemas provided by the vendors.  The solution is to very carefully extend your AD schema to support additional attributes.  Some of this work is already done by I2 MACE with eduperson.  In the same manner, you should look to create a private schema to populate in AD that extends the attributes with more useful values including multivalued attributes.

Go to IANA and register an OID  arc for your institution if you have not already done so, then look at examples from other institutions  and your own needs regarding what A/V pairs meet the minimum requirements for your current and possible future needs.  It would be very helpful to enlist a company or individual with experience creating and maintaining OID arcs and LDAP A/V pairs that has done this type of integration before.

I have always found the following book a good reference (from the creator himself) as well as Michael Gettes' LDAP recipe

Tim Howes, et. al. "Understanding and Deploying LDAP"



Good Luck
Barry

On 05/29/2012 01:07 PM, Mike Shore wrote:
Hi everyone,
 
We use SungardHE Ellucian Banner as our ERP, and AD as our authentication directory. We are moving towards a Microsoft-centric environment, with Exchange, Sharepoint and eventually Lync. We have hit a problem whereby some staff have multiple jobs (ie. part time instructor, as well as full time Payroll clerk). In these cases, Banner is able to track multiple jobs for a single person. However, AD only supports single values for attributes like Department, Job Title and Supervisor.
 
I realize there is no simple way to map multiple values in Banner down to a single value in AD. We have tried to determine what the person’s “primary” job is, based on hours committed to each job and other criteria. We have also considered using custom AD attributes to store additional information about an employee, but that info might not be visible to other AD-aware apps that are looking at specific attributes.
 
Another issue is workflow. If an employee’s manager needs to sign off on something, how does AD know which manager should be part of a particular workflow?
 
Are you in a similar situation? Have you managed to overcome this limitation and if so, what did you do and what kinds of compromises were required? We need to solve these issues before we travel too far down the Microsoft/AD path.
 
Mike Shore
Intermediate Systems Analyst
Business Application Services Team, IT Services
British Columbia Institute of Technology
3700 Willingdon Avenue, Burnaby, BC, V5G 3H2
 
Tel: 604-412-7474 · Fax: 604-439-6785
Email: mshore@bcit.ca · Web: www.bcit.ca/its
 
It's your career. Get it right.
"We are generally the better persuaded by the reasons we discover ourselves than by those given to us by others." - Blaise Pascal
P   Please consider the environment before printing this e-mail
 
 
 

AD is a critical piece of our infrastructure but it is not your main directory product.  We use a different, more standards based, directory to collect identity attributes from our systems of record and then populate from that what AD will accommodate.  AD is used for systems and services that require AD.  Most everything else references our main directory where attributes are more standard.  The title attribute is a perfect example.  In AD it is not only single value but it is also constrained in length contrary to RFC.  We have multiple titles and titles that exceed the allowed length in AD.

 

I reject the notion of ‘primary’.  Many applications require you to make an arbitrary decision because they assume people only have one job or affiliation.  But in practice a person’s primary job is the one they happen to be doing from one moment to the next.

 

In my opinion AD is simply the wrong product to use if your application or service must be multiple affiliation aware.

 

Message from mike_shore@bcit.ca

At the moment it is simply an attribute update issue. If a person has multiple job titles/departments/supervisors, we would ideally store and retrieve the information in AD without a lot of customization. We do access management via group memberships, which is relatively easy to control.

 

AD (like all data repositories) comes with two considerations: data storage abilities and assumptions out-of-the-box applications make. Here is what we've learned about some of your questions.

1) Focus the usually-single-valued attributes (title, department, mail, etc) on what you print in your CampusDirectory page. If you'd print two paragraphs (one per job, or one for a student's major and another for their job), then mapping into AD will be difficult, and you'll probably need some self-service (and/or delegated-administration) ways for people to pick between their roles. Most applications won't use a custom/multi-role-rendering attribute, so it's probably not worth populating.

2) Encode as much affiliation/role information into group memberships, as that is where applications will succeed at leveraging multivalued data.

3) For supervisor information... OOTB workflows will probably only be able to use a single-valued supervisor, so pick a 90% solution (Who Signs Timesheet (of job with most hours)). Other hierarchies (Annual Reviewer, Manager, etc) could be put into other single-valued, custom attributes. However, don't bother encoding everything into AD... Workflows that need to support a variety of supervisor hierarchies will probably need to be heavily customized, and it will be easier to keep their data relational rather than flattening Department/Supervisor information into custom ldap attributes. I would certainly not expose Banner's schema to those applications (or to anyone I liked) but instead would provide SqlServer tables/views that provide the supervisor flexibility your workflows require.



Bert Bee-Lindgren, Identity Management & Middleware
   Office of Information Technology/EIS :: Georgia Tech
   bert.bee-lindgren@oit.gatech.edu
   W: 877-237-8251 :: SMS: 402-237-8251 :: AIM: BertBeeLindgren
   https://mail.gatech.edu/home/bl17?fmt=freebusy  (my availability)

From: "Mike Shore" <Mike_Shore@BCIT.CA>
To: IDM@LISTSERV.EDUCAUSE.EDU
Sent: Tuesday, May 29, 2012 2:07:08 PM
Subject: [IDM] Mapping Banner to AD

Hi everyone,
 
We use SungardHE Ellucian Banner as our ERP, and AD as our authentication directory. We are moving towards a Microsoft-centric environment, with Exchange, Sharepoint and eventually Lync. We have hit a problem whereby some staff have multiple jobs (ie. part time instructor, as well as full time Payroll clerk). In these cases, Banner is able to track multiple jobs for a single person. However, AD only supports single values for attributes like Department, Job Title and Supervisor.
 
I realize there is no simple way to map multiple values in Banner down to a single value in AD. We have tried to determine what the person’s “primary” job is, based on hours committed to each job and other criteria. We have also considered using custom AD attributes to store additional information about an employee, but that info might not be visible to other AD-aware apps that are looking at specific attributes.
 
Another issue is workflow. If an employee’s manager needs to sign off on something, how does AD know which manager should be part of a particular workflow?
 
Are you in a similar situation? Have you managed to overcome this limitation and if so, what did you do and what kinds of compromises were required? We need to solve these issues before we travel too far down the Microsoft/AD path.
 
Mike Shore
Intermediate Systems Analyst
Business Application Services Team, IT Services
British Columbia Institute of Technology
3700 Willingdon Avenue, Burnaby, BC, V5G 3H2
 
Tel: 604-412-7474 · Fax: 604-439-6785
Email: mshore@bcit.ca · Web: www.bcit.ca/its
 
It's your career. Get it right.
"We are generally the better persuaded by the reasons we discover ourselves than by those given to us by others." - Blaise Pascal
P   Please consider the environment before printing this e-mail
 
 
 

Hi Mike, I would echo the remarks below.

We've got a similar situation, where most of our LDAP-aware applications are subscribed to a dedicated LDAP server for attribute-lookup purposes.  We've deployed eduPerson schema there, and made other schema extensions as needed to suit particular LDAP clients.  ACIs are customized based on application and privacy-policy needs.

Our AD system is used for those MS-applications that need it, and contains a standard OOB schema.  Attribute access controls are a subject of ongoing conversation, as you know.

Corey S.


On 05/29/2012 11:27 AM, Jones, Mark B wrote:
AD is a critical piece of our infrastructure but it is not your main directory product.  We use a different, more standards based, directory to collect identity attributes from our systems of record and then populate from that what AD will accommodate.  AD is used for systems and services that require AD.  Most everything else references our main directory where attributes are more standard.  The title attribute is a perfect example.  In AD it is not only single value but it is also constrained in length contrary to RFC.  We have multiple titles and titles that exceed the allowed length in AD.

Message from joel_avery@yahoo.ca

Hi Mike,

The AD is what I call an "application specific directory". Any time a system relies on another directory (or business process) for their needs, they are subject to these foreign systems rules, limitations and requirements.

It appears that the business decision to move to a Microsoft centric technology environment does not support your identity business requirements. This means either that the requirement cannot be fulfilled "properly" or that a different technical solution is required.

I will second the opinion that a more flexible directory solution be used as BCIT's general purpose directory and AD be relegated to the directory supporting systems that require the use of AD. Initially, the list of applications using the new directory may be small, but you will be able to migrate other systems from AD to the new directory over time.
 
Joel Avery
613 725 4859

Providing Strategic Technology Planning for your Enterprise
http://www.linkedin.com/in/joelavery

From: Mike Shore <Mike_Shore@BCIT.CA>
To: IDM@LISTSERV.EDUCAUSE.EDU
Sent: Tuesday, May 29, 2012 2:07:08 PM
Subject: [IDM] Mapping Banner to AD

Hi everyone,
 
We use SungardHE Ellucian Banner as our ERP, and AD as our authentication directory. We are moving towards a Microsoft-centric environment, with Exchange, Sharepoint and eventually Lync. We have hit a problem whereby some staff have multiple jobs (ie. part time instructor, as well as full time Payroll clerk). In these cases, Banner is able to track multiple jobs for a single person. However, AD only supports single values for attributes like Department, Job Title and Supervisor.
 
I realize there is no simple way to map multiple values in Banner down to a single value in AD. We have tried to determine what the person’s “primary” job is, based on hours committed to each job and other criteria. We have also considered using custom AD attributes to store additional information about an employee, but that info might not be visible to other AD-aware apps that are looking at specific attributes.
 
Another issue is workflow. If an employee’s manager needs to sign off on something, how does AD know which manager should be part of a particular workflow?
 
Are you in a similar situation? Have you managed to overcome this limitation and if so, what did you do and what kinds of compromises were required? We need to solve these issues before we travel too far down the Microsoft/AD path.
 
Mike Shore
Intermediate Systems Analyst
Business Application Services Team, IT Services
British Columbia Institute of Technology
3700 Willingdon Avenue, Burnaby, BC, V5G 3H2
 
Tel: 604-412-7474 · Fax: 604-439-6785
Email: mshore@bcit.ca · Web: www.bcit.ca/its
 
It's your career. Get it right.
"We are generally the better persuaded by the reasons we discover ourselves than by those given to us by others." - Blaise Pascal
P   Please consider the environment before printing this e-mail
 
 
 


I'd agree that AD has some rigidity like an application specific directory has, but I wouldn't agree that necessarily makes it unfit for identity management directory purposes. Obviously, many companies are using only AD for their enterprise directory, and AD's market share has gotten to the point where it's pretty much ubiquitous. There are really good reasons why AD has been so successful, which makes it pretty hard to dismiss it.

 

Mike is trying to map Banner data to AD. The way I read it, there's no chance that AD won't be part of their environment, because Exchange, Lync, etc, require it.

 

There are many solutions I can imagine to the problem(s):

1. Deploy AD-LDS together with AD. AD-LDS leverages AD based authN (see userproxy objects), but unlike AD, gives you complete flexibility in terms of the schema definition. Populate the AD-LDS objects with the multi-valued data, and also find some best single value to stick in the AD single-valued attribute. You can then point applications which want multi-valued data at AD-LDS, but don't break those applications which will only integrate with AD.

2. Add your own custom attributes to AD. Push the multi-valued Banner data to these custom attributes. Find some best single value to stick in the AD single-valued attribute. You can then point applications which want multi-valued data at your custom attributes, but don't break those applications which will only integrate with the single-valued default AD attributes.

3. Deploy a virtual directory. Find some best single value to stick in the AD single-valued attribute. Deploy the multi-valued data to some other data store (SQL?). Configure the virtual directory to leverage AD plus the other data store. You can then point applications which want multi-valued data at the virtual directory, but don't break those applications which will only integrate with the single-valued default AD attributes.

4. Deploy some other directory product. Same story as above ... use this other directory product for apps which need multi-valued, and use AD for the AD integrated stuff.

5. You might try pushing those pesky apps which require AD into the cloud. But then you'd still need to provision the cloud AD. ;)

 

Some possibilities for finding the best single value might include:

-a hierarchy of the source systems, e.g. employee data values trump student data values

-a natural preference per user based on the source data, e.g. the title from a 75% departmental appointment would be preferred over the title from the 25% departmental appointment

-an arbitrary system (e.g. alphabetically 1st value)

-put the choice of which value is provisioned to AD in the hands of the user

 

You could have some combination of the above, e.g. there is a default choice until the user chooses, and the user choice then overrides the default.

 

Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.