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
And here's a snapshot of our current hierarchy: 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
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]> 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
*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]> 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
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]> 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
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]> 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 and Information Systems Division Argonne National Laboratory ITSA: Providing Effective and Efficient IT Management Solutions
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]> 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 and Information Systems Division Argonne National Laboratory
ITSA: Providing Effective and Efficient IT Management Solutions
-- Craig
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]<mailto:[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<http://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]<mailto:[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]<mailto:[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]<mailto:[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
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
Current data means getting our account information (uid, group membership, etc) as well as other information we use like netgroups. On Apr 1, 2013, at 1:39 PM, Craig Stacey <[email protected]> wrote:
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
Oh! I don't see any problem with groups and group memberships. And, where existing AD attributes, as is, will accommodate your needs, we are good. Collaborator accounts are really for people who do not plan to come on site and their access will be to resources outside of the firewall. Otherwise, they may fit better into the category of on-site people who are users of an on-site resource - like the APS or ATLAS. The latter have regular accounts. Rich -----Original Message----- From: Ti Leggett [mailto:[email protected]] Sent: Monday, April 01, 2013 1:47 PM To: Stacey, Craig J. Cc: Raffenetti, Richard C.; Martin, Tamara L.; Schmidt, Karl E.; Lehman, David S.; [email protected] Admins Subject: Re: LDAP Attributes Current data means getting our account information (uid, group membership, etc) as well as other information we use like netgroups. On Apr 1, 2013, at 1:39 PM, Craig Stacey <[email protected]> wrote:
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
Hi Rich, We would like to ramp up this effort again, with the hope of interfacing with a test environment in the next two weeks. To expand on the collaborator account needs - some of the applications in our environment that we use for collaboration require the same unix attributes that we use for normal user accounts. Therefore, our resource manager (userbase) needs access to those attributes on collaborator account as well as standard account objects. For user account adds / removals we would follow the standard procedures currently in place. For the modification methods listed below we need programmatic access through the standard LDAP methods. The "must have" attributes on user and collaborator accounts that we would need write access to from a service account are:
gidNumber homeDirectory loginShell uidNumber
The following attributes are in use, but we assume the CIS user management facilities already populate these attributes with appropriate values (ie, mail is set to the user's preferred email address for collaborator accounts):
cn dc description displayName dn givenName homePhone homePostalAddress mail roomNumber sn telephoneNumber uid
For each topic listed below we need programmatic access to add / delete / modify each object through the standard LDAP methods. For group management we would need: 1. The ability to create groups in our OU with the posixGroup object class. 2. The ability to add collaborator accounts and standard accounts to groups in our OU. For netgroups we would need:
nisNetgroupTriple nisNetgroup objectClass
For automount we would need:
automountInformation automount objectClass automountMap objectClass
For testing all of this we would need test OU, a test collaborator account and a test service account that we can assign to userbase. We plan on using this to modify and test our normal resource management workflows. ----- Original Message -----
From: "Richard C. Raffenetti" <[email protected]> To: "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]> Sent: Monday, April 1, 2013 2:12:05 PM Subject: RE: LDAP Attributes
Oh! I don't see any problem with groups and group memberships. And, where existing AD attributes, as is, will accommodate your needs, we are good.
Collaborator accounts are really for people who do not plan to come on site and their access will be to resources outside of the firewall. Otherwise, they may fit better into the category of on-site people who are users of an on-site resource - like the APS or ATLAS. The latter have regular accounts.
Rich
-----Original Message----- From: Ti Leggett [mailto:[email protected]] Sent: Monday, April 01, 2013 1:47 PM To: Stacey, Craig J. Cc: Raffenetti, Richard C.; Martin, Tamara L.; Schmidt, Karl E.; Lehman, David S.; [email protected] Admins Subject: Re: LDAP Attributes
Current data means getting our account information (uid, group membership, etc) as well as other information we use like netgroups.
On Apr 1, 2013, at 1:39 PM, Craig Stacey <[email protected]> wrote:
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
Hi Rich, My team spoke about this again this morning, and we've changed our approach. Because we support a lot of users from other divisions, we would wind up needing access to much more of the directory than we would like to make this work. Because of this we're going to just use AD for authentication, and we're going to continue to use our own openldap directory server for resource management. Thanks for considering this idea. ----- Original Message -----
From: "Dan Olson" <[email protected]> To: "Richard C. Raffenetti" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]>, "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Sent: Tuesday, April 23, 2013 1:57:53 PM Subject: Re: LDAP Attributes
Hi Rich,
We would like to ramp up this effort again, with the hope of interfacing with a test environment in the next two weeks.
To expand on the collaborator account needs - some of the applications in our environment that we use for collaboration require the same unix attributes that we use for normal user accounts. Therefore, our resource manager (userbase) needs access to those attributes on collaborator account as well as standard account objects.
For user account adds / removals we would follow the standard procedures currently in place. For the modification methods listed below we need programmatic access through the standard LDAP methods.
The "must have" attributes on user and collaborator accounts that we would need write access to from a service account are:
gidNumber homeDirectory loginShell uidNumber
The following attributes are in use, but we assume the CIS user management facilities already populate these attributes with appropriate values (ie, mail is set to the user's preferred email address for collaborator accounts):
cn dc description displayName dn givenName homePhone homePostalAddress mail roomNumber sn telephoneNumber uid
For each topic listed below we need programmatic access to add / delete / modify each object through the standard LDAP methods.
For group management we would need: 1. The ability to create groups in our OU with the posixGroup object class. 2. The ability to add collaborator accounts and standard accounts to groups in our OU.
For netgroups we would need:
nisNetgroupTriple nisNetgroup objectClass
For automount we would need:
automountInformation automount objectClass automountMap objectClass
For testing all of this we would need test OU, a test collaborator account and a test service account that we can assign to userbase. We plan on using this to modify and test our normal resource management workflows.
----- Original Message -----
From: "Richard C. Raffenetti" <[email protected]> To: "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]> Sent: Monday, April 1, 2013 2:12:05 PM Subject: RE: LDAP Attributes
Oh! I don't see any problem with groups and group memberships. And, where existing AD attributes, as is, will accommodate your needs, we are good.
Collaborator accounts are really for people who do not plan to come on site and their access will be to resources outside of the firewall. Otherwise, they may fit better into the category of on-site people who are users of an on-site resource - like the APS or ATLAS. The latter have regular accounts.
Rich
-----Original Message----- From: Ti Leggett [mailto:[email protected]] Sent: Monday, April 01, 2013 1:47 PM To: Stacey, Craig J. Cc: Raffenetti, Richard C.; Martin, Tamara L.; Schmidt, Karl E.; Lehman, David S.; [email protected] Admins Subject: Re: LDAP Attributes
Current data means getting our account information (uid, group membership, etc) as well as other information we use like netgroups.
On Apr 1, 2013, at 1:39 PM, Craig Stacey <[email protected]> wrote:
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
Dan, After I received your earlier note and having the information from prior emails I was creating a meeting to get the stakeholders in CIS up to speed. Your most recent note answers the largest issue that we would have had to deal with, i.e. what about attributes that are not in Active Directory. I believe that in the end, the use of a custom ldap will be needed. There is a generic ldap capability available in Windows called Adam, which, I believe, has useful and reliable synchronization with AD. That is an available option. We do not have any Adam instances that I know of. I have our internal meeting set for Thursday. I think it would be useful for you and I to meet informally. Are you available today? I am not expecting to be here Wednesday. Rich -----Original Message----- From: Dan Olson [mailto:[email protected]] Sent: Thursday, April 25, 2013 10:03 PM To: Raffenetti, Richard C. Cc: Martin, Tamara L.; Lehman, David S.; Schmidt, Karl E.; [email protected] Admins; Leggett, Torrance I.; Stacey, Craig J. Subject: Re: LDAP Attributes Hi Rich, My team spoke about this again this morning, and we've changed our approach. Because we support a lot of users from other divisions, we would wind up needing access to much more of the directory than we would like to make this work. Because of this we're going to just use AD for authentication, and we're going to continue to use our own openldap directory server for resource management. Thanks for considering this idea. ----- Original Message -----
From: "Dan Olson" <[email protected]> To: "Richard C. Raffenetti" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]>, "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Sent: Tuesday, April 23, 2013 1:57:53 PM Subject: Re: LDAP Attributes
Hi Rich,
We would like to ramp up this effort again, with the hope of interfacing with a test environment in the next two weeks.
To expand on the collaborator account needs - some of the applications in our environment that we use for collaboration require the same unix attributes that we use for normal user accounts. Therefore, our resource manager (userbase) needs access to those attributes on collaborator account as well as standard account objects.
For user account adds / removals we would follow the standard procedures currently in place. For the modification methods listed below we need programmatic access through the standard LDAP methods.
The "must have" attributes on user and collaborator accounts that we would need write access to from a service account are:
gidNumber homeDirectory loginShell uidNumber
The following attributes are in use, but we assume the CIS user management facilities already populate these attributes with appropriate values (ie, mail is set to the user's preferred email address for collaborator accounts):
cn dc description displayName dn givenName homePhone homePostalAddress mail roomNumber sn telephoneNumber uid
For each topic listed below we need programmatic access to add / delete / modify each object through the standard LDAP methods.
For group management we would need: 1. The ability to create groups in our OU with the posixGroup object class. 2. The ability to add collaborator accounts and standard accounts to groups in our OU.
For netgroups we would need:
nisNetgroupTriple nisNetgroup objectClass
For automount we would need:
automountInformation automount objectClass automountMap objectClass
For testing all of this we would need test OU, a test collaborator account and a test service account that we can assign to userbase. We plan on using this to modify and test our normal resource management workflows.
----- Original Message -----
From: "Richard C. Raffenetti" <[email protected]> To: "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]> Sent: Monday, April 1, 2013 2:12:05 PM Subject: RE: LDAP Attributes
Oh! I don't see any problem with groups and group memberships. And, where existing AD attributes, as is, will accommodate your needs, we are good.
Collaborator accounts are really for people who do not plan to come on site and their access will be to resources outside of the firewall. Otherwise, they may fit better into the category of on-site people who are users of an on-site resource - like the APS or ATLAS. The latter have regular accounts.
Rich
-----Original Message----- From: Ti Leggett [mailto:[email protected]] Sent: Monday, April 01, 2013 1:47 PM To: Stacey, Craig J. Cc: Raffenetti, Richard C.; Martin, Tamara L.; Schmidt, Karl E.; Lehman, David S.; [email protected] Admins Subject: Re: LDAP Attributes
Current data means getting our account information (uid, group membership, etc) as well as other information we use like netgroups.
On Apr 1, 2013, at 1:39 PM, Craig Stacey <[email protected]> wrote:
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
Sounds good, I sent you an invite. It looks like 3188 is available at 11am. ----- Original Message -----
From: "Richard C. Raffenetti" <[email protected]> To: "Daniel E. Murphy-Olson" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]>, "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Sent: Tuesday, April 30, 2013 10:12:22 AM Subject: RE: LDAP Attributes
Dan, After I received your earlier note and having the information from prior emails I was creating a meeting to get the stakeholders in CIS up to speed. Your most recent note answers the largest issue that we would have had to deal with, i.e. what about attributes that are not in Active Directory. I believe that in the end, the use of a custom ldap will be needed. There is a generic ldap capability available in Windows called Adam, which, I believe, has useful and reliable synchronization with AD. That is an available option. We do not have any Adam instances that I know of. I have our internal meeting set for Thursday. I think it would be useful for you and I to meet informally. Are you available today? I am not expecting to be here Wednesday. Rich
-----Original Message----- From: Dan Olson [mailto:[email protected]] Sent: Thursday, April 25, 2013 10:03 PM To: Raffenetti, Richard C. Cc: Martin, Tamara L.; Lehman, David S.; Schmidt, Karl E.; [email protected] Admins; Leggett, Torrance I.; Stacey, Craig J. Subject: Re: LDAP Attributes
Hi Rich,
My team spoke about this again this morning, and we've changed our approach. Because we support a lot of users from other divisions, we would wind up needing access to much more of the directory than we would like to make this work.
Because of this we're going to just use AD for authentication, and we're going to continue to use our own openldap directory server for resource management.
Thanks for considering this idea.
----- Original Message -----
From: "Dan Olson" <[email protected]> To: "Richard C. Raffenetti" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]>, "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Sent: Tuesday, April 23, 2013 1:57:53 PM Subject: Re: LDAP Attributes
Hi Rich,
We would like to ramp up this effort again, with the hope of interfacing with a test environment in the next two weeks.
To expand on the collaborator account needs - some of the applications in our environment that we use for collaboration require the same unix attributes that we use for normal user accounts. Therefore, our resource manager (userbase) needs access to those attributes on collaborator account as well as standard account objects.
For user account adds / removals we would follow the standard procedures currently in place. For the modification methods listed below we need programmatic access through the standard LDAP methods.
The "must have" attributes on user and collaborator accounts that we would need write access to from a service account are:
gidNumber homeDirectory loginShell uidNumber
The following attributes are in use, but we assume the CIS user management facilities already populate these attributes with appropriate values (ie, mail is set to the user's preferred email address for collaborator accounts):
cn dc description displayName dn givenName homePhone homePostalAddress mail roomNumber sn telephoneNumber uid
For each topic listed below we need programmatic access to add / delete / modify each object through the standard LDAP methods.
For group management we would need: 1. The ability to create groups in our OU with the posixGroup object class. 2. The ability to add collaborator accounts and standard accounts to groups in our OU.
For netgroups we would need:
nisNetgroupTriple nisNetgroup objectClass
For automount we would need:
automountInformation automount objectClass automountMap objectClass
For testing all of this we would need test OU, a test collaborator account and a test service account that we can assign to userbase. We plan on using this to modify and test our normal resource management workflows.
----- Original Message -----
From: "Richard C. Raffenetti" <[email protected]> To: "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]> Sent: Monday, April 1, 2013 2:12:05 PM Subject: RE: LDAP Attributes
Oh! I don't see any problem with groups and group memberships. And, where existing AD attributes, as is, will accommodate your needs, we are good.
Collaborator accounts are really for people who do not plan to come on site and their access will be to resources outside of the firewall. Otherwise, they may fit better into the category of on-site people who are users of an on-site resource - like the APS or ATLAS. The latter have regular accounts.
Rich
-----Original Message----- From: Ti Leggett [mailto:[email protected]] Sent: Monday, April 01, 2013 1:47 PM To: Stacey, Craig J. Cc: Raffenetti, Richard C.; Martin, Tamara L.; Schmidt, Karl E.; Lehman, David S.; [email protected] Admins Subject: Re: LDAP Attributes
Current data means getting our account information (uid, group membership, etc) as well as other information we use like netgroups.
On Apr 1, 2013, at 1:39 PM, Craig Stacey <[email protected]> wrote:
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
Dan, We had a meeting yesterday. Based on our discussions, that you will use an LDAP to manage your resources and use ANL accounts for resource users, there was one question. How will you handle UoC Computation Institute members? As I understand it, they are not in our HR database. They could get collaborator accounts and possibly some other types of account which will put them into HR and therefore meet all of the Laboratory's needs. Possibly you told me but it did not register. Rich -----Original Message----- From: Dan Olson [mailto:[email protected]] Sent: Tuesday, April 30, 2013 10:20 AM To: Raffenetti, Richard C. Cc: Martin, Tamara L.; Lehman, David S.; Schmidt, Karl E.; [email protected] Admins; Leggett, Torrance I.; Stacey, Craig J. Subject: Re: LDAP Attributes Sounds good, I sent you an invite. It looks like 3188 is available at 11am. ----- Original Message -----
From: "Richard C. Raffenetti" <[email protected]> To: "Daniel E. Murphy-Olson" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]>, "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Sent: Tuesday, April 30, 2013 10:12:22 AM Subject: RE: LDAP Attributes
Dan, After I received your earlier note and having the information from prior emails I was creating a meeting to get the stakeholders in CIS up to speed. Your most recent note answers the largest issue that we would have had to deal with, i.e. what about attributes that are not in Active Directory. I believe that in the end, the use of a custom ldap will be needed. There is a generic ldap capability available in Windows called Adam, which, I believe, has useful and reliable synchronization with AD. That is an available option. We do not have any Adam instances that I know of. I have our internal meeting set for Thursday. I think it would be useful for you and I to meet informally. Are you available today? I am not expecting to be here Wednesday. Rich
-----Original Message----- From: Dan Olson [mailto:[email protected]] Sent: Thursday, April 25, 2013 10:03 PM To: Raffenetti, Richard C. Cc: Martin, Tamara L.; Lehman, David S.; Schmidt, Karl E.; [email protected] Admins; Leggett, Torrance I.; Stacey, Craig J. Subject: Re: LDAP Attributes
Hi Rich,
My team spoke about this again this morning, and we've changed our approach. Because we support a lot of users from other divisions, we would wind up needing access to much more of the directory than we would like to make this work.
Because of this we're going to just use AD for authentication, and we're going to continue to use our own openldap directory server for resource management.
Thanks for considering this idea.
----- Original Message -----
From: "Dan Olson" <[email protected]> To: "Richard C. Raffenetti" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]>, "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Sent: Tuesday, April 23, 2013 1:57:53 PM Subject: Re: LDAP Attributes
Hi Rich,
We would like to ramp up this effort again, with the hope of interfacing with a test environment in the next two weeks.
To expand on the collaborator account needs - some of the applications in our environment that we use for collaboration require the same unix attributes that we use for normal user accounts. Therefore, our resource manager (userbase) needs access to those attributes on collaborator account as well as standard account objects.
For user account adds / removals we would follow the standard procedures currently in place. For the modification methods listed below we need programmatic access through the standard LDAP methods.
The "must have" attributes on user and collaborator accounts that we would need write access to from a service account are:
gidNumber homeDirectory loginShell uidNumber
The following attributes are in use, but we assume the CIS user management facilities already populate these attributes with appropriate values (ie, mail is set to the user's preferred email address for collaborator accounts):
cn dc description displayName dn givenName homePhone homePostalAddress mail roomNumber sn telephoneNumber uid
For each topic listed below we need programmatic access to add / delete / modify each object through the standard LDAP methods.
For group management we would need: 1. The ability to create groups in our OU with the posixGroup object class. 2. The ability to add collaborator accounts and standard accounts to groups in our OU.
For netgroups we would need:
nisNetgroupTriple nisNetgroup objectClass
For automount we would need:
automountInformation automount objectClass automountMap objectClass
For testing all of this we would need test OU, a test collaborator account and a test service account that we can assign to userbase. We plan on using this to modify and test our normal resource management workflows.
----- Original Message -----
From: "Richard C. Raffenetti" <[email protected]> To: "Torrance I. Leggett" <[email protected]>, "Craig J. Stacey" <[email protected]> Cc: "Tamara L. Martin" <[email protected]>, "David S. Lehman" <[email protected]>, "Karl E. Schmidt" <[email protected]>, "[email protected] Admins" <[email protected]> Sent: Monday, April 1, 2013 2:12:05 PM Subject: RE: LDAP Attributes
Oh! I don't see any problem with groups and group memberships. And, where existing AD attributes, as is, will accommodate your needs, we are good.
Collaborator accounts are really for people who do not plan to come on site and their access will be to resources outside of the firewall. Otherwise, they may fit better into the category of on-site people who are users of an on-site resource - like the APS or ATLAS. The latter have regular accounts.
Rich
-----Original Message----- From: Ti Leggett [mailto:[email protected]] Sent: Monday, April 01, 2013 1:47 PM To: Stacey, Craig J. Cc: Raffenetti, Richard C.; Martin, Tamara L.; Schmidt, Karl E.; Lehman, David S.; [email protected] Admins Subject: Re: LDAP Attributes
Current data means getting our account information (uid, group membership, etc) as well as other information we use like netgroups.
On Apr 1, 2013, at 1:39 PM, Craig Stacey <[email protected]> wrote:
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
participants (6)
-
Craig Stacey -
Dan Olson -
Raffenetti, Richard C. -
Schmidt, Karl E. -
Tami Martin -
Ti Leggett