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." <[email protected]> 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:[email protected]] 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.; [email protected] 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 <[email protected]> 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:[email protected]] Sent: Thursday, March 28, 2013 9:24 AM To: Schmidt, Karl E. Cc: [email protected] Admins; Martin, Tamara L.; Lehman, David S. Subject: Re: LDAP Attributes
*ping*
On Mar 21, 2013, at 9:49 AM, Ti Leggett <[email protected]> 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 <[email protected]. 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 <[email protected]> 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