COmanage Users List

[Mike Manske <>]

Here's what we do - there may be a more modern way, and maybe this
would not apply to you. Anyway, we created a new extended type,
'employeeNumber' with display name 'Employee Number', then created a
new identifier assignment of that type using <some letters indicating
CO> + <sequential number>. This gets created for a CO person at
enrollment and you can also generate it after the enrolment, and also
as a batch. (Note, we have multiple COs that get sent to the same LDAP
instance, so we use a CO prefix in the id assignment to prevent
collisions.)

In the enrollment flow, we set an attribute 'eppn id' to  'Indentifier
(ePPN Organizational Identity)'  and check 'Copy this attribute to the
CO Person record' and it is required.

In the LDAP provisioner, we specify "People DN Identifier Type" =
'Employee Number' (it is now in the drop down of possible values). In
the 'People DN Attribute Name' we put 'employeeNumber'. You can call
it whatever. For 'People Base DN', we set it to 'ou=people,o=<our CO>,
dc=<host>, etc., but you will have to tailor it to your needs. (I
won't bore you with the LDAP Attributes section unless you need it.)

In LDAP, we get this, (using made up values): DN:
employeeNumber=XYZ1003,ou=people,o=MY-PROJ,dc=whatsamatta,dc=you,dc=edu.
And in the 'eduPersonPrincipalName' attribute we have the horrible but
necessary google id, for example, 
''.
Ugly but it works.

Good luck -
Mike
On Wed, Aug 29, 2018 at 1:56 PM Kevin M. Hildebrand 
<>
 wrote:
>
> Reviving a very old thread...
>
> I understand your recommendation about not using eppn in the dn.  When 
> generating the opaque identifier as you suggest, what attribute would you 
> suggest I use to hold that identifier?  What's a good practice for building 
> a dn?  I was using dn: 
> ,ou=Users,dc=test,dc=umd,dc=edu,
>   and copying the eppn to the uid field as they'll both be the same here.
> Would this be an appropriate use for eduPersonUniqueId?  (dn: 
> ,ou=Users...)
>
> Thanks,
> Kevin
>
>
>
>
> On Thu, Apr 13, 2017 at 8:55 PM Benn Oshrin 
> <>
>  wrote:
>>
>> To reply with more detail...
>>
>> For the most part what you're asking for is
>> https://bugs.internet2.edu/jira/browse/CO-1137 (which I think is what
>> was brought up a few days ago on list). The complication is that even
>> when we implement that capability (I think we're trying to get it done
>> for the next feature release), you'll still run into the issue that eppn
>> is attached to the org identity, and not the CO Person record.
>>
>> I could offer a couple of options for how to work around that
>> (pipelines, enrollment forms, new RFEs related to the new $ENV OIS we're
>> planning), but instead I'd actually rather push back and suggest that
>> eppn might not be the best choice for a DN component, which needs to
>> uniquely identify a person in LDAP.
>>
>> (1) What happens if a person has more than one eppn? If they've linked a
>> gmail account and a university.edu account, which one do you pick?
>>
>> (2) What happens when the eppn changes? Say I registered with
>> 
>>  but then later decide I don't want my personal gmail
>> address associated with the registration. (COmanage can handle a DN
>> change, but downstream applications might not be able to.)
>>
>> A better approach is to use Identifier Assignments to create a CO
>> specific opaque identifier (something like "UMD123456") and then use
>> that to populate the DN. This way there is a one to one relationship
>> between a CO Person identifier and an LDAP DN, and it doesn't change
>> based on external factors. You can still look up records based on eppn
>> by having the LDAP Provisioner write the eppn into the LDAP record.
>>
>> Thanks,
>>
>> -Benn-
>>
>> On 4/10/17 6:04 PM, Kevin M. Hildebrand wrote:
>> > That works for most of the ldap attributes but I can't create a dn that
>> > way.
>> > I'd like my dn to have the eppn in it, and have the uid match.
>> > i.e.,
>> > dn: 
>> > 
>> >  
>> > <mailto:>,dc=test,dc=umd,dc=edu
>> >
>> > I was thinking, perhaps an expansion of the fields available in the
>> > automatic identifier assignment would help- right now you can build
>> > identifiers with tokens from the user's name, how about expanding that
>> > to allow more generic expansion.
>> > Then I can build uid from eppn, and use that for my dn.
>> > Alternatively, the dn creation options should also allow one to pull
>> > values from the org record.
>> >
>> > Kevin
>> >
>> > On Apr 10, 2017 18:21, "Benn Oshrin" 
>> > <
>> > <mailto:>>
>> >  wrote:
>> >
>> >     In the LDAP provisioner attribute configuration, you should see an
>> >     option "Use value from Organizational Identity" that does what you 
>> > want.
>> >     I thought this was documented in the wiki somewhere, but I can't
>> >     find it...
>> >
>> >     (In general you can't export Org Identity attributes because they're 
>> > not
>> >     "operational", but there are limited exceptions primarily for this 
>> > use
>> >     case.)
>> >
>> >     Thanks,
>> >
>> >     -Benn-
>> >
>> >     On 4/10/17 9:06 AM, Kevin M. Hildebrand wrote:
>> >     > I'm having some challenges creating the LDAP dn that I want based 
>> > on
>> >     > attributes obtained via self-signup.
>> >     >
>> >     > I've got authenticated self-signup working, using Google auth.  
>> > That
>> >     > populates ePPN in the Organizational Identity with the
>> >     authenticated ID
>> >     > (I'm currently having it use the Google user's email address).
>> >     >
>> >     > The problem I'm having is that the LDAP provisioner only seems to 
>> > want
>> >     > to draw items from the CO person record, and self-signup doesn't
>> >     > populate that record with much.
>> >     >
>> >     > For example if I set my 'People DN Identifier Type' in the 
>> > provisioner
>> >     > to ePPN, the provisioning fails because ePPN isn't defined in the 
>> > CO
>> >     > person record.
>> >     >
>> >     > I'd like to have the authenticated ID passed in from Google get
>> >     assigned
>> >     > to ePPN in a form available to the LDAP provisioner so I can build
>> >     a DN
>> >     > from it.  Perhaps by automatically copying it to the CO person 
>> > record,
>> >     > or perhaps a way to allow the LDAP provisioner to export
>> >     attributes from
>> >     > the Organizational record.
>> >     >
>> >     > Thanks,
>> >     > Kevin
>> >     >
>> >     > --
>> >     > Kevin Hildebrand
>> >     > University of Maryland, College Park
>> >     >
>> >