Well, we're looking to be able to push attributes into AD that will be used by our systems, such as group memberships and UIDs.

As for the other questions, I'll let Ti expand, but the crux of 2 is that we were led to believe we could push data into AD (such as that mentioned above), so we need to test that, and for 3, the issue is we want to test the situation when someone comes from being an offsite collaborator to being an employee and how we will handle that in our system.
--
Craig

On Apr 1, 2013, at 1:35 PM, "Raffenetti, Richard C." <RRaffenetti@anl.gov> wrote:

Regarding administering collaborator accounts:
Historically we have no structure in AD which provides a convenient way to delegate authority over collaborator accounts.  However, the structure we do have for collaborator accounts could easily be changed to be organization-oriented and then the delegation could be to the same or different persons who hold the delegation for their organization.  I have to wonder about the need to administer collaborator accounts, given the limitations of those accounts – as once conceived.  Reset passwords ok, what else?  Many of the attributes can be edited, especially where they do not jeopardize security.  If the AD structure is changed, then the same collaborator account attributes would be available to administer as the regular accounts.
 
1.       As mentioned earlier, we have self-service password resets and that is working well.
2.       I’m not appreciating this question – what data?
3.       We do not convert collaborator accounts to ordinary accounts or vice versa.  When collaborators come on-site, they get a personal ANL account.  When employees become collaborators, they acquire a collaborator account.  A person is active either as a collaborator or as an on-site person (employee, contractor, …) but not as both.  (We have an exception for employees who need an active collaborator account for testing.)
 
We don’t control any access to resources - except for the resources we administer – like Sharepoint.  Resource managers dis/allow accounts to use resources.
 
Let me know if I can expand on anything.
Rich
 
From: Craig Stacey [mailto:stace@mcs.anl.gov] 
Sent: Thursday, March 28, 2013 6:45 PM
To: Martin, Tamara L.; Schmidt, Karl E.
Cc: Lehman, David S.; Leggett, Torrance I.; Raffenetti, Richard C.; core-admins@mcs.anl.gov Admins
Subject: Re: LDAP Attributes
 

Actually, I'm more concerned with what OU the collaborator accounts will live in, and whether we'll have ou admin rights on them.

Specifically, will we be able to administer these accounts the same way we can our regular accounts?

Tami Martin <tamim@anl.gov> wrote:
Ti/Karl,

Collaborator account password resets are done by the help desk through a 
tool that is not distributed by division.  There is an account profile 
tool at mypassword.anl.gov that can be used by the collaborator to reset 
passwords if they have a profile defined. cc'd Rich for input.


Thanks,
Tami

On 3/28/13 4:08 PM, Schmidt, Karl E. wrote:
Sorry, Ti. (and thank you for the ping)

I am still looking into the LDAP attributes.

If those are available, #2 and #2 shouldn't be an issue...I do not know the business rules around #1.  Tami, do you know where password resets are done?

-Karl

-----Original Message-----

 From:
Ti Leggett [mailto:leggett@mcs.anl.gov]
Sent: Thursday, March 28, 2013 9:24 AM
To: Schmidt, Karl E.
Cc: core-admins@mcs.anl.gov Admins; Martin, Tamara L.; Lehman, David S.
Subject: Re: LDAP Attributes

*ping*

On Mar 21, 2013, at 9:49 AM, Ti Leggett <leggett@mcs.anl.gov> wrote:
3 things that we just thought of.

1) Would we have the ability to do password resets for MCS collaborator accounts?
2) Can we get a test OU that we can use to test migrating our current data in to test out how this will work and how we will start using this for all of our services
3) Can we get a test collaborator OU that we can use to test converting from a collaborator to regular and vice versa and how that will affect our services


On Feb 26, 2013, at 8:37 AM, Ti Leggett <leggett@mcs.anl.
 gov>
wrote:
And here's a snapshot of our current hierarchy:

<Screen Shot 2013-02-26 at 8.36.48 AM.png>

On Feb 26, 2013, at 8:35 AM, Ti Leggett <leggett@mcs.anl.gov> wrote:
Here's the list of all the object classes and attributes we use. Obviously the Samba ones could probably be replaced with MS AD specific ones.

Object Classes:
account
automount
automountMap
dcObject
inetOrgPerson
ldapPublicKey
nisNetgroup
organizationalRole
organizationalUnit
person
posixAccount
posixGroup
sambaDomain
sambaSamAccount
sambaUnixIdPool
simpleSecurityObject
top
uidObject

Attributes:
automountInformation
cn
dc
description
displayName
dn
employeeType
gidNumber
givenName
homeDirectory
homePhone
homePostalAddress
loginShell
mail
memberUid
nisNetgroupTriple
objectClass
ou
roomNumber
sambaAcctFlags
sambaDomainName
sambaForceLogoff
sambaKickoffTime
sambaLockoutDuration
sambaLockoutObservationWindow
sambaLockoutThreshold
sambaLogoffTime
sambaLogonTime
sambaLogonToChgPwd
sambaMaxPwdAge
sambaMinPwdAge
sambaMinPwdLength
sambaNextRid
sambaNTPassword
sambaPrimaryGroupSID
sambaPwdCanChange
sambaPwdHistoryLength
sambaPwdLastSet
sambaPwdMustChange
sambaSID
sn
sshPublicKey
telephoneNumber
uid
uidNumber
 
-- 
Tami Martin
630-252-7372
IT Service Automation Manager
Computer an
 d
Information Systems Division
Argonne National Laboratory

ITSA: Providing Effective and Efficient IT Management Solutions




-- Craig