RE: [ActiveDir] UAC Question
Thank you all. I will give a serious look at account expiration, that might work also. Again, I was originally looking at account lockout because the tools and permissions already exist to unlock an account by certain help desk members and I wouldn't have to provide additional tools and training. David Aragon > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Monday, August 21, 2006 3:19 PM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] UAC Question > > Yeah I was thinking about forcing pwdLastSet to 0 or forcing > an account expiration (versus password expiration) with the > accountExpires attribute. > The former can be bypassed if someone knows the password, > they can change the old password and be up and running. The > other would require an admin interaction. > > joe > > > -- > O'Reilly Active Directory Third Edition - > http://www.joeware.net/win/ad3e.htm > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan > Sent: Monday, August 21, 2006 5:46 PM > To: ActiveDir@mail.activedir.org > Subject: Re: [ActiveDir] UAC Question > > That's a good explanation. I don't see how you can lock them > out programmatically though. The mechanism just isn't > designed to do that. > You'd have to force bad auth attempts on them constantly. > > If you can't disable the AD account, what if you expired it? > That would prevent login too, right? You could just set the > expiration date back to an > > unexpired value when you need to. > > Just a thought... > > Joe K. > - Original Message - > From: David Aragon > To: ActiveDir@mail.activedir.org > Sent: Monday, August 21, 2006 3:14 PM > Subject: RE: [ActiveDir] UAC Question > > > I think I need to expand the picture here to provide more > clarity. At the > top of our tree we have openLDAP which we refer to as the > Enterprise and > which is the authoritative source for all credentials. That > feeds several > sub-systems, including Active Directory, email, SMB, etc. We have > internally developed connectors to provide each sub-system > the appropriate > user information including passwords (when required by that > sub-system). > This has afforded us a working single-sign on for multiple platforms > (Windows, MAC, & Linux). Users can go to any computer, any > platform, and > their credentials are valid (though there might be local > restrictions). > Users go to a single point to change their password and that > change is then > appropriately encrypted and transmitted to each sub-system in > a form that is > > best for that sub-system. This all works quite well, > however, because of > this we can not change the user's password in AD without > causing a break > between the Enterprise and AD user objects. Forcing a change in the > password of a user object at the Enterprise level would cut > the user off > from their email, personal network shares, etc. > > A couple of years ago the telephony group paid a LOT of money > for this > software (let me repeat here that I was not involved until > recently). A few > > months after the purchase, the company was bought by a larger > company who > apparently didn't bother keeping any of the original developers, > programmers, etc. though they continue to "support" the > software. We have > been told on numerous occasions, however, that because we have an > unconventional setup, we are virtually on our own and no one > wants to cough > up another big chunk of money to replace the software. The software > requires a voice mailbox be tied to an active Directory user > account, but > once created, the only check that is made is if the AD user > account is > enabled or disabled. > > I recently complained that we were leaving a possible > security hole by not > doing something with these accounts and, as typically > happens, I was tasked > with coming up with an appropriate solution. At the time, it > seemed the > easiest path to follow would be to set the account lockout > which would > prevent the user from logging into the vast majority of > systems, but still > allow them the ability to get their email (from off campus), > vm (from off > campus or on campus), etc. This is still the path I'm pursuing. > > David Aragon > > > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Grillenmeier, Guido > Sent: Monday, August 21, 2006 10:53 AM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] UAC Question > > > Adding a dummy workstation will hinder the user to logon > interactively - > this could be all you want to achieve. But it won't hinder > network logons - > this may be undesired. > > Another thought - if the users aren't really using their AD account, > couldn't > you just change the PW to some complex dummy pwd? This would > ensure that the > > user wo
RE: [ActiveDir] [OT] Process for requesting, authorizing and creating shares?
I think it can vary wildly. Best case would be some sort of workflow with the business rules and automated notification for approval by stakeholders. This is normally something that would have to be tied to some sort of funding as well, especially for something as crazy as a 500GB request. When the money ended so would the shared space... If the data use would be something more realistic like a few GB, the F-5 would end up placing a new folder on the local Proj server under the pre-existing PROJ share and cleanup would occur after any review to determine what still was and what wasn't currently in use. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, August 20, 2006 11:41 PM To: activedir@mail.activedir.org Subject: RE: [ActiveDir] [OT] Process for requesting, authorizing and creating shares? Thanks, Joe. I tend to agree regarding standard names, no random driver letters, etc. (which you could probably already infer from my initial e-mail/post). However, that doesn't really answer the question of what the process should look like when, for example, creating a new PROJ-related share and/or folder? Example - a new, large project starts up, and a PM asks to allocate a 50GB share somewhere. How do you figure out where to put it? What if there is no available server with adequate free space? How do you tell that the project has wound down, and it's a good time to recover that disk space for new work? What happened in this scenario when you worked at that Fortune-5 where you used to (still do?) work? Cheers, -- Idan -- Forwarded message -- Date: Fri, 18 Aug 2006 21:00:58 -0400 From: joe <[EMAIL PROTECTED]> Reply-To: ActiveDir@mail.activedir.org To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OT] Process for requesting, authorizing and creating shares? Resent-Date: Sun, 20 Aug 2006 21:37:10 -0600 (MDT) Resent-From: Idan <[EMAIL PROTECTED]> Resent-To: Idan Shoham <[EMAIL PROTECTED]> Resent-Subject: RE: [ActiveDir] [OT] Process for requesting, authorizing and creating shares? In general I think it is better for larger orgs to have a very locked down strong share policy. Even down to specifying specific standard share names, permissions (like auth users FC and then locking with NTFS unless there will be no change access then R). For instance names like APPS, PROJ, DATA, BINS, etc. One large multinational you are familiar with has shares for users as username$, then shared file served applications or application installation packages are located in APPS, and all group shared data goes into a share called PROJ and permissioning is handled at the folder level. The software delivery system uses another hidden share but it is a single name across the entire enterprise. The only thing that varies are the servers. This makes life easier for the users and the administrators. People aren't browsing to find things and/or trying to recall what the sharename was... I like having as few shares as possible because I have seen too many cases of alphabet soup with connected drive letters where users get to the point that they only know what drive letters they had, not what they were connected to. I recall in a job back in the mid-90's where any given user of about 2000 at the local site was connected to about 10-12 shares but what shares they were connected to depended on what part of the building they were in and what department they were in. We had to carry around a pocket guide to the areas so when someone said I need my I: drive back you knew exactly what share to connect for them. If someone would rather have an ad hoc system, I would say follow any normal provisioning process with workflow. I wouldn't want to have to come in and clean that up in 5 years though once someone finally realizes how ridiculous it is because everyone is running out of drive letters to use. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 9:21 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Process for requesting, authorizing and creating shares? Hi folks, Slightly off-topic here -- i.e,. related to managing Windows environments generally, rather than just Active Directory. I'm wondering whether any of you have seen good business processes for managing share creation (and for that matter, deletion)? We are working with a large multi-national where the current process by which business users request new shares (i.e., network-attached, shared, access-controlled disk space), and by which those requests are approved and implemented, is pretty weak. We are hoping to help them automate this process, but would obviously like to lock it down first. For exampl
RE: [ActiveDir] UAC Question
Yeah I was thinking about forcing pwdLastSet to 0 or forcing an account expiration (versus password expiration) with the accountExpires attribute. The former can be bypassed if someone knows the password, they can change the old password and be up and running. The other would require an admin interaction. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Monday, August 21, 2006 5:46 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] UAC Question That's a good explanation. I don't see how you can lock them out programmatically though. The mechanism just isn't designed to do that. You'd have to force bad auth attempts on them constantly. If you can't disable the AD account, what if you expired it? That would prevent login too, right? You could just set the expiration date back to an unexpired value when you need to. Just a thought... Joe K. - Original Message - From: David Aragon To: ActiveDir@mail.activedir.org Sent: Monday, August 21, 2006 3:14 PM Subject: RE: [ActiveDir] UAC Question I think I need to expand the picture here to provide more clarity. At the top of our tree we have openLDAP which we refer to as the Enterprise and which is the authoritative source for all credentials. That feeds several sub-systems, including Active Directory, email, SMB, etc. We have internally developed connectors to provide each sub-system the appropriate user information including passwords (when required by that sub-system). This has afforded us a working single-sign on for multiple platforms (Windows, MAC, & Linux). Users can go to any computer, any platform, and their credentials are valid (though there might be local restrictions). Users go to a single point to change their password and that change is then appropriately encrypted and transmitted to each sub-system in a form that is best for that sub-system. This all works quite well, however, because of this we can not change the user's password in AD without causing a break between the Enterprise and AD user objects. Forcing a change in the password of a user object at the Enterprise level would cut the user off from their email, personal network shares, etc. A couple of years ago the telephony group paid a LOT of money for this software (let me repeat here that I was not involved until recently). A few months after the purchase, the company was bought by a larger company who apparently didn't bother keeping any of the original developers, programmers, etc. though they continue to "support" the software. We have been told on numerous occasions, however, that because we have an unconventional setup, we are virtually on our own and no one wants to cough up another big chunk of money to replace the software. The software requires a voice mailbox be tied to an active Directory user account, but once created, the only check that is made is if the AD user account is enabled or disabled. I recently complained that we were leaving a possible security hole by not doing something with these accounts and, as typically happens, I was tasked with coming up with an appropriate solution. At the time, it seemed the easiest path to follow would be to set the account lockout which would prevent the user from logging into the vast majority of systems, but still allow them the ability to get their email (from off campus), vm (from off campus or on campus), etc. This is still the path I'm pursuing. David Aragon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Monday, August 21, 2006 10:53 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] UAC Question Adding a dummy workstation will hinder the user to logon interactively - this could be all you want to achieve. But it won't hinder network logons - this may be undesired. Another thought - if the users aren't really using their AD account, couldn't you just change the PW to some complex dummy pwd? This would ensure that the user wouldn't be able to use the account for any AD authentication - until they come back from their sabbatical and the helpdesk resets the pwd for them. Also, I'd check with the application vendor, if you can't configure it to use an attribute other than the disabled flag to see if the account should be voicemail enabled or not. This would give you much more granular control over the matter - you could disable the AD account (which it seems is really what you want to do) while still leaving the voicemail intact. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:57 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] UAC Question Why are the last two groups treated differently than the others? You may want to consider a different approach, such as c
Re: [ActiveDir] UAC Question
That's a good explanation. I don't see how you can lock them out programmatically though. The mechanism just isn't designed to do that. You'd have to force bad auth attempts on them constantly. If you can't disable the AD account, what if you expired it? That would prevent login too, right? You could just set the expiration date back to an unexpired value when you need to. Just a thought... Joe K. - Original Message - From: David Aragon To: ActiveDir@mail.activedir.org Sent: Monday, August 21, 2006 3:14 PM Subject: RE: [ActiveDir] UAC Question I think I need to expand the picture here to provide more clarity. At the top of our tree we have openLDAP which we refer to as the Enterprise and which is the authoritative source for all credentials. That feeds several sub-systems, including Active Directory, email, SMB, etc. We have internally developed connectors to provide each sub-system the appropriate user information including passwords (when required by that sub-system). This has afforded us a working single-sign on for multiple platforms (Windows, MAC, & Linux). Users can go to any computer, any platform, and their credentials are valid (though there might be local restrictions). Users go to a single point to change their password and that change is then appropriately encrypted and transmitted to each sub-system in a form that is best for that sub-system. This all works quite well, however, because of this we can not change the user's password in AD without causing a break between the Enterprise and AD user objects. Forcing a change in the password of a user object at the Enterprise level would cut the user off from their email, personal network shares, etc. A couple of years ago the telephony group paid a LOT of money for this software (let me repeat here that I was not involved until recently). A few months after the purchase, the company was bought by a larger company who apparently didn't bother keeping any of the original developers, programmers, etc. though they continue to "support" the software. We have been told on numerous occasions, however, that because we have an unconventional setup, we are virtually on our own and no one wants to cough up another big chunk of money to replace the software. The software requires a voice mailbox be tied to an active Directory user account, but once created, the only check that is made is if the AD user account is enabled or disabled. I recently complained that we were leaving a possible security hole by not doing something with these accounts and, as typically happens, I was tasked with coming up with an appropriate solution. At the time, it seemed the easiest path to follow would be to set the account lockout which would prevent the user from logging into the vast majority of systems, but still allow them the ability to get their email (from off campus), vm (from off campus or on campus), etc. This is still the path I'm pursuing. David Aragon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Monday, August 21, 2006 10:53 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] UAC Question Adding a dummy workstation will hinder the user to logon interactively - this could be all you want to achieve. But it won't hinder network logons - this may be undesired. Another thought - if the users aren't really using their AD account, couldn't you just change the PW to some complex dummy pwd? This would ensure that the user wouldn't be able to use the account for any AD authentication - until they come back from their sabbatical and the helpdesk resets the pwd for them. Also, I'd check with the application vendor, if you can't configure it to use an attribute other than the disabled flag to see if the account should be voicemail enabled or not. This would give you much more granular control over the matter - you could disable the AD account (which it seems is really what you want to do) while still leaving the voicemail intact. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:57 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] UAC Question Why are the last two groups treated differently than the others? You may want to consider a different approach, such as changing to the workstations that they can logon to or expiring the account. On 8/21/06, David Aragon <[EMAIL PROTECTED]> wrote: Al, Thank you for your response, I will try to elaborate, but first, let me start by saying that I was not invited to participate in this application's selection, testing, or acceptance. One day it just showed up. That said ... The software we use for VOIP uses its own db for storing messages. It was supposed to be AD aware. It's not. It is (barely) LDAP aware. I've found that when a user checks their voice mail (after they enter in their pass code) t
RE: [ActiveDir] UAC Question
I think I need to expand the picture here to provide more clarity. At the top of our tree we have openLDAP which we refer to as the Enterprise and which is the authoritative source for all credentials. That feeds several sub-systems, including Active Directory, email, SMB, etc. We have internally developed connectors to provide each sub-system the appropriate user information including passwords (when required by that sub-system). This has afforded us a working single-sign on for multiple platforms (Windows, MAC, & Linux). Users can go to any computer, any platform, and their credentials are valid (though there might be local restrictions). Users go to a single point to change their password and that change is then appropriately encrypted and transmitted to each sub-system in a form that is best for that sub-system. This all works quite well, however, because of this we can not change the user's password in AD without causing a break between the Enterprise and AD user objects. Forcing a change in the password of a user object at the Enterprise level would cut the user off from their email, personal network shares, etc. A couple of years ago the telephony group paid a LOT of money for this software (let me repeat here that I was not involved until recently). A few months after the purchase, the company was bought by a larger company who apparently didn't bother keeping any of the original developers, programmers, etc. though they continue to "support" the software. We have been told on numerous occasions, however, that because we have an unconventional setup, we are virtually on our own and no one wants to cough up another big chunk of money to replace the software. The software requires a voice mailbox be tied to an active Directory user account, but once created, the only check that is made is if the AD user account is enabled or disabled. I recently complained that we were leaving a possible security hole by not doing something with these accounts and, as typically happens, I was tasked with coming up with an appropriate solution. At the time, it seemed the easiest path to follow would be to set the account lockout which would prevent the user from logging into the vast majority of systems, but still allow them the ability to get their email (from off campus), vm (from off campus or on campus), etc. This is still the path I'm pursuing. David Aragon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, GuidoSent: Monday, August 21, 2006 10:53 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] UAC Question Adding a dummy workstation will hinder the user to logon interactively – this could be all you want to achieve. But it won’t hinder network logons – this may be undesired. Another thought – if the users aren’t really using their AD account, couldn’t you just change the PW to some complex dummy pwd? This would ensure that the user wouldn’t be able to use the account for any AD authentication – until they come back from their sabbatical and the helpdesk resets the pwd for them… Also, I’d check with the application vendor, if you can’t configure it to use an attribute other than the disabled flag to see if the account should be voicemail enabled or not. This would give you much more granular control over the matter – you could disable the AD account (which it seems is really what you want to do) while still leaving the voicemail intact. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Monday, August 21, 2006 6:57 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] UAC Question Why are the last two groups treated differently than the others? You may want to consider a different approach, such as changing to the workstations that they can logon to or expiring the account. On 8/21/06, David Aragon <[EMAIL PROTECTED]> wrote: Al, Thank you for your response, I will try to elaborate, but first, let me start by saying that I was not invited to participate in this application's selection, testing, or acceptance. One day it just showed up. That said ... The software we use for VOIP uses its own db for storing messages. It was supposed to be AD aware. It's not. It is (barely) LDAP aware. I've found that when a user checks their voice mail (after they enter in their pass code) the program only checks to see if their AD account is enabled or disabled. We do have a password policy that does exactly what you describe (locks users out for some period of time after x invalid attempts). We have also given the senior Help Desk staff the ability to unlock an account under certain circumstances. We have some (a couple hundred) accounts that exis
RE: [ActiveDir] UAC Question
Adding a dummy workstation will hinder the user to logon interactively – this could be all you want to achieve. But it won’t hinder network logons – this may be undesired. Another thought – if the users aren’t really using their AD account, couldn’t you just change the PW to some complex dummy pwd? This would ensure that the user wouldn’t be able to use the account for any AD authentication – until they come back from their sabbatical and the helpdesk resets the pwd for them… Also, I’d check with the application vendor, if you can’t configure it to use an attribute other than the disabled flag to see if the account should be voicemail enabled or not. This would give you much more granular control over the matter – you could disable the AD account (which it seems is really what you want to do) while still leaving the voicemail intact. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:57 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] UAC Question Why are the last two groups treated differently than the others? You may want to consider a different approach, such as changing to the workstations that they can logon to or expiring the account. On 8/21/06, David Aragon <[EMAIL PROTECTED]> wrote: Al, Thank you for your response, I will try to elaborate, but first, let me start by saying that I was not invited to participate in this application's selection, testing, or acceptance. One day it just showed up. That said ... The software we use for VOIP uses its own db for storing messages. It was supposed to be AD aware. It's not. It is (barely) LDAP aware. I've found that when a user checks their voice mail (after they enter in their pass code) the program only checks to see if their AD account is enabled or disabled. We do have a password policy that does exactly what you describe (locks users out for some period of time after x invalid attempts). We have also given the senior Help Desk staff the ability to unlock an account under certain circumstances. We have some (a couple hundred) accounts that exist to handle the section or group vm for those areas where individuals that share a phone number. These, I have identified and developed methods that prevent them from being used as login accounts. I have also found that there are users that do not have a computer and never use a computer, but they have vm enabled on their phone. We also have users that take sabbaticals for 6 months to a year. It is these last two groups I was hoping to address with setting the UAC account lockout. Politically I can not disable the accounts. I have tried to add the accounts to the permanent lockout list which works, but when the last groups returns it takes time for us to remove them from the list. Again politically unacceptable. This makes us having the ability to set the account lockout very appealing. What I was looking for was a way to set the lockout bit. It was previously explained that the bit can not be set directly, but that by setting the lockoutTime to some non-zero value the account is locked (though I've found that the bit is not always set). My current research and testing is moving along that path. David Aragon From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:33 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] UAC Question This part troubles me: "(for example it will prevent a user from logging into a system, but not prevent them from getting their voicemail)." Can you expand on that? To my thinking, if the account is locked out, then the user should not be able to use it. Period. End of story. No exceptions. Locked out functionality is there as a precaution to prevent misuse of the identity (ok, account.) Why would you want to subvert that? What benefit that cannot be achieved in another manner? Again, to my way of thinking, there is no reason you would ever want to mess with it in your day to day. A better option would be to set it to automatically clear after a certain period which would prevent hackers, crackers, and script kiddies (side note: set it to something that would cause a cracker to take longer to realistically crack than the password change cycle) from obtaining the passwords of the accounts. For example, .5 hours lockout after x number of attempts means that for every x number of attempts, anyone trying to programmatically trying to guess passwords would have to pause for .5 hours before resumption. If you have hu
Re: [ActiveDir] UAC Question
Why are the last two groups treated differently than the others? You may want to consider a different approach, such as changing to the workstations that they can logon to or expiring the account. On 8/21/06, David Aragon <[EMAIL PROTECTED]> wrote: Al, Thank you for your response, I will try to elaborate, but first, let me start by saying that I was not invited to participate in this application's selection, testing, or acceptance. One day it just showed up. That said ... The software we use for VOIP uses its own db for storing messages. It was supposed to be AD aware. It's not. It is (barely) LDAP aware. I've found that when a user checks their voice mail (after they enter in their pass code) the program only checks to see if their AD account is enabled or disabled. We do have a password policy that does exactly what you describe (locks users out for some period of time after x invalid attempts). We have also given the senior Help Desk staff the ability to unlock an account under certain circumstances. We have some (a couple hundred) accounts that exist to handle the section or group vm for those areas where individuals that share a phone number. These, I have identified and developed methods that prevent them from being used as login accounts. I have also found that there are users that do not have a computer and never use a computer, but they have vm enabled on their phone. We also have users that take sabbaticals for 6 months to a year. It is these last two groups I was hoping to address with setting the UAC account lockout. Politically I can not disable the accounts. I have tried to add the accounts to the permanent lockout list which works, but when the last groups returns it takes time for us to remove them from the list. Again politically unacceptable. This makes us having the ability to set the account lockout very appealing. What I was looking for was a way to set the lockout bit. It was previously explained that the bit can not be set directly, but that by setting the lockoutTime to some non-zero value the account is locked (though I've found that the bit is not always set). My current research and testing is moving along that path. David Aragon From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Monday, August 21, 2006 6:33 AM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] UAC Question This part troubles me: "(for example it will prevent a user from logginginto a system, but not prevent them from getting their voicemail)." Can you expand on that? To my thinking, if the account is locked out, then the user should not be able to use it. Period. End of story. No exceptions. Locked out functionality is there as a precaution to prevent misuse of the identity (ok, account.) Why would you want to subvert that? What benefit that cannot be achieved in another manner? Again, to my way of thinking, there is no reason you would ever want to mess with it in your day to day. A better option would be to set it to automatically clear after a certain period which would prevent hackers, crackers, and script kiddies (side note: set it to something that would cause a cracker to take longer to realistically crack than the password change cycle) from obtaining the passwords of the accounts. For example, .5 hours lockout after x number of attempts means that for every x number of attempts, anyone trying to programmatically trying to guess passwords would have to pause for .5 hours before resumption. If you have hundreds of thousands of possible passwords and combinations, that can make the time to crack longer than the password change interval if you design it that way. My initial take on this is that you're trying to do something and that there's a better/more supported way to accomplish it. Am I missing something? On 8/2/06, David Aragon <[EMAIL PROTECTED] > wrote: http://support.microsoft.com/kb/305144/ discusses the various property flags for the UserAccountControl (UAC). I have tried to set different flags usingLDP, ADSIEdit, and _vbscript_. One flag in particular is giving me a lot of grief, LOCKOUT. I can clear the bit, but can not set it. This is useful to set for a number of reasons (for example it will prevent a user from logginginto a system, but not prevent them from getting their voicemail). Is this normal? Can it be set and if so, how? Is it dependent on other settings (ex. lockoutTime) to be set to remain set?David AragonList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Viewing GPO processing
No, verbose userenv logging simply tells you what is happening during each step of GP processing. It doesn't log what is happening as the user is executing commands that may run into policy. We actually had a conversation with the GP team at MS about this particular issue because it is very difficult to troubleshoot. I don't think a network trace is going to help since the problem is not during policy application but when the policy has already been applied and there is some unexpected reaction between an application and what could be a totally unrelated (usually) shell restriction. For example, back in the NT 4 days I spent hours trying to troubleshoot why a particular 16-bit app would throw weird errors whenever we tried starting it. Through a process of elimination, I figured that it was choking on the "Hide Drives" policy that hid certain drive letters from Explorer. This was primarily due to the fact that the particular API the app was using was relying on the visibility of the drive letter, rather than a more standard way of accessing that information. So, its really hard to pin this kind of stuff down unless you get lucky with Regmon or just remove one policy item at a time until you find the problematic one. Darren Darren Mar-Elia For comprehensive Windows Group Policy Information, check out www.gpoguy.com-- the best source for GPO FAQs, video training, tools and whitepapers. Also check out the Windows Group Policy Guide, the definitive resource for Group Policy information. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernesto Nieto Sent: Monday, August 21, 2006 8:52 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Viewing GPO processing Darren, Thanks yes, that's what I want to find out. I did read something in previous emails about using network trace on the group policy, but I have no clue on how to do that. Would enabling verbose userenv logging help, you think? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Monday, August 21, 2006 10:23 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Viewing GPO processing Assuming its XP, then you can use GPMC to get a GP Results report that tells you what GPOs and what settings were applied to a given user or computer. However, I think what you're asking is, is there any log that tells you when a particular operation gets blocked by a particular GPO setting, and the answer to that is no. Depending upon what the operation is, you may be able to see what registry values are getting queried (assuming it's an admin. Template policy that is causing the problem) by using Sysinternals Regmon to spy on the registry I/O while you are doing the particular operation described below. However, outside of that its trial and error to find why the operation is getting stopped. Darren Darren Mar-Elia For comprehensive Windows Group Policy Information, check out www.gpoguy.com-- the best source for GPO FAQs, video training, tools and whitepapers. Also check out the Windows Group Policy Guide, the definitive resource for Group Policy information. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernesto Nieto Sent: Monday, August 21, 2006 8:05 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Viewing GPO processing Is there anyway to see when a GPO is being applied. Is there a log somewhere that shows what was applied and what wasn't? Like the log that's created when one logs into w2k in safe mode. In that log, you can see what drivers are loaded. I need to see what policy is causing an error when users log on. The error is about installing an .INF file, access is denied. Thank you List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Viewing GPO processing
Darren, Thanks yes, that's what I want to find out. I did read something in previous emails about using network trace on the group policy, but I have no clue on how to do that. Would enabling verbose userenv logging help, you think? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Monday, August 21, 2006 10:23 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Viewing GPO processing Assuming its XP, then you can use GPMC to get a GP Results report that tells you what GPOs and what settings were applied to a given user or computer. However, I think what you're asking is, is there any log that tells you when a particular operation gets blocked by a particular GPO setting, and the answer to that is no. Depending upon what the operation is, you may be able to see what registry values are getting queried (assuming it's an admin. Template policy that is causing the problem) by using Sysinternals Regmon to spy on the registry I/O while you are doing the particular operation described below. However, outside of that its trial and error to find why the operation is getting stopped. Darren Darren Mar-Elia For comprehensive Windows Group Policy Information, check out www.gpoguy.com-- the best source for GPO FAQs, video training, tools and whitepapers. Also check out the Windows Group Policy Guide, the definitive resource for Group Policy information. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernesto Nieto Sent: Monday, August 21, 2006 8:05 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Viewing GPO processing Is there anyway to see when a GPO is being applied. Is there a log somewhere that shows what was applied and what wasn't? Like the log that's created when one logs into w2k in safe mode. In that log, you can see what drivers are loaded. I need to see what policy is causing an error when users log on. The error is about installing an .INF file, access is denied. Thank you List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Viewing GPO processing
Assuming its XP, then you can use GPMC to get a GP Results report that tells you what GPOs and what settings were applied to a given user or computer. However, I think what you're asking is, is there any log that tells you when a particular operation gets blocked by a particular GPO setting, and the answer to that is no. Depending upon what the operation is, you may be able to see what registry values are getting queried (assuming it's an admin. Template policy that is causing the problem) by using Sysinternals Regmon to spy on the registry I/O while you are doing the particular operation described below. However, outside of that its trial and error to find why the operation is getting stopped. Darren Darren Mar-Elia For comprehensive Windows Group Policy Information, check out www.gpoguy.com-- the best source for GPO FAQs, video training, tools and whitepapers. Also check out the Windows Group Policy Guide, the definitive resource for Group Policy information. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernesto Nieto Sent: Monday, August 21, 2006 8:05 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Viewing GPO processing Is there anyway to see when a GPO is being applied. Is there a log somewhere that shows what was applied and what wasn't? Like the log that's created when one logs into w2k in safe mode. In that log, you can see what drivers are loaded. I need to see what policy is causing an error when users log on. The error is about installing an .INF file, access is denied. Thank you List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] UAC Question
Al, Thank you for your response, I will try to elaborate, but first, let me start by saying that I was not invited to participate in this application's selection, testing, or acceptance. One day it just showed up. That said ... The software we use for VOIP uses its own db for storing messages. It was supposed to be AD aware. It's not. It is (barely) LDAP aware. I've found that when a user checks their voice mail (after they enter in their pass code) the program only checks to see if their AD account is enabled or disabled. We do have a password policy that does exactly what you describe (locks users out for some period of time after x invalid attempts). We have also given the senior Help Desk staff the ability to unlock an account under certain circumstances. We have some (a couple hundred) accounts that exist to handle the section or group vm for those areas where individuals that share a phone number. These, I have identified and developed methods that prevent them from being used as login accounts. I have also found that there are users that do not have a computer and never use a computer, but they have vm enabled on their phone. We also have users that take sabbaticals for 6 months to a year. It is these last two groups I was hoping to address with setting the UAC account lockout. Politically I can not disable the accounts. I have tried to add the accounts to the permanent lockout list which works, but when the last groups returns it takes time for us to remove them from the list. Again politically unacceptable. This makes us having the ability to set the account lockout very appealing. What I was looking for was a way to set the lockout bit. It was previously explained that the bit can not be set directly, but that by setting the lockoutTime to some non-zero value the account is locked (though I've found that the bit is not always set). My current research and testing is moving along that path. David Aragon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Monday, August 21, 2006 6:33 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] UAC Question This part troubles me: "(for example it will prevent a user from logginginto a system, but not prevent them from getting their voicemail)." Can you expand on that? To my thinking, if the account is locked out, then the user should not be able to use it. Period. End of story. No exceptions. Locked out functionality is there as a precaution to prevent misuse of the identity (ok, account.) Why would you want to subvert that? What benefit that cannot be achieved in another manner? Again, to my way of thinking, there is no reason you would ever want to mess with it in your day to day. A better option would be to set it to automatically clear after a certain period which would prevent hackers, crackers, and script kiddies (side note: set it to something that would cause a cracker to take longer to realistically crack than the password change cycle) from obtaining the passwords of the accounts. For example, .5 hours lockout after x number of attempts means that for every x number of attempts, anyone trying to programmatically trying to guess passwords would have to pause for .5 hours before resumption. If you have hundreds of thousands of possible passwords and combinations, that can make the time to crack longer than the password change interval if you design it that way. My initial take on this is that you're trying to do something and that there's a better/more supported way to accomplish it. Am I missing something? On 8/2/06, David Aragon <[EMAIL PROTECTED]> wrote: http://support.microsoft.com/kb/305144/ discusses the various property flags for the UserAccountControl (UAC). I have tried to set different flags usingLDP, ADSIEdit, and _vbscript_. One flag in particular is giving me a lot ofgrief, LOCKOUT. I can clear the bit, but can not set it. This is useful to set for a number of reasons (for example it will prevent a user from logginginto a system, but not prevent them from getting their voicemail).Is this normal? Can it be set and if so, how? Is it dependent on other settings (ex. lockoutTime) to be set to remain set?David AragonList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
Re: [ActiveDir] Can the Gods return to our domain? an ex-DC naming question
If I were you, rather than put Exchange on a DC, I would put the second DC on an older but still robust workstation (and beefed up to boot). A long way from Best Practices, but still preferable to the Taboo Mix. - Original Message - From: "Steven Johnston" <[EMAIL PROTECTED]> To: Sent: Monday, August 21, 2006 2:24 AM Subject: RE: [ActiveDir] Can the Gods return to our domain? an ex-DC naming question Firstly I would like to say thanks for all the help. I probably wasnt as clear in my original description about a few things as I could have been so I will go over the assumptions some of you made that were incorrect. Ok so from my notes.. -- Existing Environment The existing environment contains 2 Domain Controllers running Windows 2000 Server named Ceres and Hades, the Domain operates in Mixed Mode. Ceres has all of the FSMO roles (RID, PDC, Infrastructure, Domain Naming and Schema), runs DNS, Blackberry Enterprise Server, VERITAS Backup Exec, acts as a Print Server, WINS server and the GC. Hades acts as a DHCP, DNS Server and runs Exchange 2000 Server with Symantec Mail Security 5.0. The DHCP options for 006 DNS Server only point to Hades IP address and not to Ceres. The new server to replace the Exchange Server “Insert Server Name Here - Server3� is running Windows Server 2003 Standard. -- Ceres is a very old server that was once an NT4 pdc and hence doesnt have the minimum spec to run 2k3, this is why I will probably literally dump it. Hades is also quite an old server but was introduced when the W2k domain was introduced, I will be keeping Hades to use only as a DC (running DNS in ADI mode) and probably to run BES and Backup Exec. Server3 is a brand new server (slightly over spec'ed probably - if thats possible), I will be using Server3 for Exchange 2k3 but also need a second DC when Ceres is removed so this will probably fill that role. My current plan included installing E2k3 and then dcpromo'ing but as you say this isnt supported so I wont be doing this - Thanks for the heads up I will just juggle my plans around to DCPROMO and then install E2K3, I dont think that will cause an issue. I need to edit my current plan and make quite a few updates, thanks for the suggestions. Are there any other items of concern in the above environment. (ignore the blackberrys, I will just uninstall and install that from scratch again I think as they are a massive hassle, or maybe I will let Ceres remain as a BES server only) Thanks Steven -Original Message- From: [EMAIL PROTECTED] on behalf of Almeida Pinto, Jorge de Sent: Fri 8/18/2006 11:44 PM To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org Cc: Subject: RE: [ActiveDir] Can the Gods return to our domain? an ex-DC naming question In your case I would: * execute from the E2K3 media: SETUP /FORESTPREP (this preps your forest for E2K3 servers) (this will resolve the incorrect attributes in a W2K AD with E2K) * execute from the E2K3 media: SETUP /DOMAINPREP (this preps your domain for E2K3 servers) * execute from the W2K3-SP1 media: ADPREP /FORESTPREP (this preps your forest for W2K3 DCs) * execute from the W2K3-SP1 media: ADPREP /DOMAINPREP /GPPREP (this preps your domain and SYSVOL for W2K3 DCs) * Install W2K3 on server3 and join to the domain, install E2K3 on server3 * Move ALL Exchange stuff from HADES to server3 (follow KB articles, etc.) * Move other roles and services (e.g. DNS,WINS,DHCP,etc.) from HADES to CERES if these do not exist yet on CERES * Decommission HADES as a server provinding Exchange services (uninstall exchange, follow KB articles, etc.) * If needed MOVE the FSMO roles from HADES to CERES * Shutdown HADES * Cleanup AD metadata for HADES on CERES (http://blogs.dirteam.com/blogs/jorge/archive/2005/12/03/213.aspx) and remove the server object manually (which is normal) (check that ALL metadata is removed!) * Re-install HADES as a W2K3 server configure TCP/IP settings accordingly and join to the domain * Promote HADES to a DC, make it a GC also * MOVE the FSMO roles from CERES to HADES * Install services like DNS,WINS,DHCP,etc. (if needed) on HADES and configure accordingly * IF NEEDED, move other roles and services (e.g. DNS,WINS,DHCP,etc.) from CERES to HADES if these do not exist yet on HADES * Shutdown CERES * Cleanup AD metadata for CERES on HADES (http://blogs.dirteam.com/blogs/jorge/archive/2005/12/03/213.aspx) and remove the server object manually (which is normal) (check that ALL metadata is removed!) (for the following steps use CERES or some other more powerfull server, but not server3 with E2K3) * Re-install CERES as a W2K3 server configure TCP/IP settings accordingly and join to the domain * Promote CERES to a DC, make it a GC also * Install services like DNS,WINS,DHCP,etc. (if needed) on CERES (or some other more powerfull server) and configure accordingly * As HADES if
[ActiveDir] Viewing GPO processing
Is there anyway to see when a GPO is being applied. Is there a log somewhere that shows what was applied and what wasn't? Like the log that's created when one logs into w2k in safe mode. In that log, you can see what drivers are loaded. I need to see what policy is causing an error when users log on. The error is about installing an .INF file, access is denied. Thank you List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
Re: RE : Re: RE : RE: [ActiveDir] backup and restore AD.
I don't know what Brett would do (is that a bracelet idea?) but personally if given the opportunity, I would have chosen to a) figure out why the failure of one disk in a RAID 5 set didn't allow for continuous operation b) fix that issue so that it never happens again (suspect disk cache, raid bios, etc) and c) flatten and repromote the new server vs. restoring the database. Why? Because it's faster, safer, cleaner and a better use of your time to do it that way. Restoring the server takes time and a lot of manual steps. Manual steps are in direct contradication to reliability because they introduce opportunity for error and judgement. Or vice-versa; I never remember which comes first. Anyway, while you can do restores, and there are times when that's the best answer, I don't believe this is one of them. At best, you have to restore and play through the last logs as well as backfill any other changes that occurred during the outage. Why yours broke over the loss of one drive in a raid set is cause for me to be concerned and not want to place that server back in service as is but rather I'd prefer to rebuild it from the ground up so that I know it's in a known state. With AD you have that option in most cases. Al On 8/19/06, Yann <[EMAIL PROTECTED]> wrote: Hello Brett, The pb was that one disk in my raid5 was corrupted. So i changed the disk and i checked that my raid 5 was OK via dell open manager.But when restarting the DC,it shows a windows popup stated an error in lssass.exe and that i have to boot in dsrm mode. When i clicked ok , my DC reboots again and that scenario never ends up untill i boot in dsrm mode !! When logging in dsrm mode, there was only the ntds.dit and the Edb*.log only, no edb.chk !! So i restored system state but when the restore finished, there was no still edb.chk created in dsrm mode: a sematic checker shows a jet error stated that no transaction logs was found. So i had 2 options: 1) restore ntds.dit, edb.chk, Edb*.log,Res1.log and Res2.log from my last full backup. This backup was done 5 days ago. 2) and i last force a demotion via ntdsutil and delete all dns registrations,frs subscriptions, ad objects that points to this DC. So i choose 1) and that works fine I was lucky !! Brett, is there any MS documentations stated that this type of "dirty" restoration is unsupported ? I have not found any clue in ms technet. And in my situation, what would you have done ? Would the 2) be the best and supported solution than 1) ? Thanks for advice. Yann Brett Shirley <[EMAIL PROTECTED]> a écrit : BTW, if you have snapshot based backup you _can_ backup and just restoreonly the AD data (dit, log, and chk), and it will work w/o USN rollbackcorrectly. We used to run quick tests like that all the time, but ONLY validated that the DS / AD didn't break. That doesn't make it supported. BTW, it is in fact _not supported_.There are an unknown # of components (AD itself, SAM, LSA, Kerberos, NTLM,AuthZ, etc ... just about anything DS or security related) that may have a dependency on some random part of AD and some random part of Registry datastaying in sync ... we don't know what breaks when you restore one w/o theother ... this is why it is unsupported ... and almost completely untested ... but why let that dissuade you, you're a pioneer right. ;)The most obvious case of this, would be if you restored a DIT from onedomain, to the DIT folder for a DC in another domain, replacing it's DIT. Would that work, almost guaranteed there would be security issues. That's of course the extreme case, and one easy to avoid, we don't knowthe inbetween cases.Cheers,-BrettSh [msft]On Fri, 18 Aug 2006, Yann wrote: > Hello Jorge,> > Thanks for clarification.> I will check next week if i have no issues with usn rollback :( . > > Yann> > "Almeida Pinto, Jorge de" a écrit : > when a DC is restored from the system state (amongst others):> * the restored RID pool is thrown away (invalidated) and a new RID pool is requested at the RID master > * the invocation ID of the AD DB is changed (which prevent USN rollbacks)> > so in your case it works because the backup is not that old. The AD DB is tightly coupled with the registry and there is a reason for that! The reason as why you MUST restore the system state as MS says. The way you are doing that is, how shall I say it gentlyNOT SUPPORTED! ;-) > And I guess you will be hitting on USN Rollback. See my blog and search for BACKUP and you will find an article with some more info> > jorge> > > - > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Yann> Sent: Tuesday, August 08, 2006 22:47> To: ActiveDir@mail.activedir.org> Subject: [ActiveDir] backup and restore AD.> > > > Hello,> > I had question about D backup & restore.> It is possible to backup AD in 2 ways: > 1) backup only the system state.> 2) backup system state & file system containing the AD working directory (ntds.dit, ed
Re: [ActiveDir] UAC Question
This part troubles me: "(for example it will prevent a user from logginginto a system, but not prevent them from getting their voicemail)." Can you expand on that? To my thinking, if the account is locked out, then the user should not be able to use it. Period. End of story. No exceptions. Locked out functionality is there as a precaution to prevent misuse of the identity (ok, account.) Why would you want to subvert that? What benefit that cannot be achieved in another manner? Again, to my way of thinking, there is no reason you would ever want to mess with it in your day to day. A better option would be to set it to automatically clear after a certain period which would prevent hackers, crackers, and script kiddies (side note: set it to something that would cause a cracker to take longer to realistically crack than the password change cycle) from obtaining the passwords of the accounts. For example, .5 hours lockout after x number of attempts means that for every x number of attempts, anyone trying to programmatically trying to guess passwords would have to pause for .5 hours before resumption. If you have hundreds of thousands of possible passwords and combinations, that can make the time to crack longer than the password change interval if you design it that way. My initial take on this is that you're trying to do something and that there's a better/more supported way to accomplish it. Am I missing something? On 8/2/06, David Aragon <[EMAIL PROTECTED]> wrote: http://support.microsoft.com/kb/305144/ discusses the various property flags for the UserAccountControl (UAC). I have tried to set different flags usingLDP, ADSIEdit, and _vbscript_. One flag in particular is giving me a lot ofgrief, LOCKOUT. I can clear the bit, but can not set it. This is useful to set for a number of reasons (for example it will prevent a user from logginginto a system, but not prevent them from getting their voicemail).Is this normal? Can it be set and if so, how? Is it dependent on other settings (ex. lockoutTime) to be set to remain set?David AragonList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Can the Gods return to our domain? an ex-DC naming question
Firstly I would like to say thanks for all the help. I probably wasnt as clear in my original description about a few things as I could have been so I will go over the assumptions some of you made that were incorrect. Ok so from my notes.. -- Existing Environment The existing environment contains 2 Domain Controllers running Windows 2000 Server named Ceres and Hades, the Domain operates in Mixed Mode. Ceres has all of the FSMO roles (RID, PDC, Infrastructure, Domain Naming and Schema), runs DNS, Blackberry Enterprise Server, VERITAS Backup Exec, acts as a Print Server, WINS server and the GC. Hades acts as a DHCP, DNS Server and runs Exchange 2000 Server with Symantec Mail Security 5.0. The DHCP options for 006 DNS Server only point to Hades IP address and not to Ceres. The new server to replace the Exchange Server “Insert Server Name Here - Server3” is running Windows Server 2003 Standard. -- Ceres is a very old server that was once an NT4 pdc and hence doesnt have the minimum spec to run 2k3, this is why I will probably literally dump it. Hades is also quite an old server but was introduced when the W2k domain was introduced, I will be keeping Hades to use only as a DC (running DNS in ADI mode) and probably to run BES and Backup Exec. Server3 is a brand new server (slightly over spec'ed probably - if thats possible), I will be using Server3 for Exchange 2k3 but also need a second DC when Ceres is removed so this will probably fill that role. My current plan included installing E2k3 and then dcpromo'ing but as you say this isnt supported so I wont be doing this - Thanks for the heads up I will just juggle my plans around to DCPROMO and then install E2K3, I dont think that will cause an issue. I need to edit my current plan and make quite a few updates, thanks for the suggestions. Are there any other items of concern in the above environment. (ignore the blackberrys, I will just uninstall and install that from scratch again I think as they are a massive hassle, or maybe I will let Ceres remain as a BES server only) Thanks Steven -Original Message- From: [EMAIL PROTECTED] on behalf of Almeida Pinto, Jorge de Sent: Fri 8/18/2006 11:44 PM To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org Cc: Subject: RE: [ActiveDir] Can the Gods return to our domain? an ex-DC naming question In your case I would: * execute from the E2K3 media: SETUP /FORESTPREP (this preps your forest for E2K3 servers) (this will resolve the incorrect attributes in a W2K AD with E2K) * execute from the E2K3 media: SETUP /DOMAINPREP (this preps your domain for E2K3 servers) * execute from the W2K3-SP1 media: ADPREP /FORESTPREP (this preps your forest for W2K3 DCs) * execute from the W2K3-SP1 media: ADPREP /DOMAINPREP /GPPREP (this preps your domain and SYSVOL for W2K3 DCs) * Install W2K3 on server3 and join to the domain, install E2K3 on server3 * Move ALL Exchange stuff from HADES to server3 (follow KB articles, etc.) * Move other roles and services (e.g. DNS,WINS,DHCP,etc.) from HADES to CERES if these do not exist yet on CERES * Decommission HADES as a server provinding Exchange services (uninstall exchange, follow KB articles, etc.) * If needed MOVE the FSMO roles from HADES to CERES * Shutdown HADES * Cleanup AD metadata for HADES on CERES (http://blogs.dirteam.com/blogs/jorge/archive/2005/12/03/213.aspx) and remove the server object manually (which is normal) (check that ALL metadata is removed!) * Re-install HADES as a W2K3 server configure TCP/IP settings accordingly and join to the domain * Promote HADES to a DC, make it a GC also * MOVE the FSMO roles from CERES to HADES * Install services like DNS,WINS,DHCP,etc. (if needed) on HADES and configure accordingly * IF NEEDED, move other roles and services (e.g. DNS,WINS,DHCP,etc.) from CERES to HADES if these do not exist yet on HADES * Shutdown CERES * Cleanup AD metadata for CERES on HADES (http://blogs.dirteam.com/blogs/jorge/archive/2005/12/03/213.aspx) and remove the server object manually (which is normal) (check that ALL metadata is removed!) (for the following steps use CERES or some other more powerfull server, but not server3 with E2K3) * Re-install CERES as a W2K3 server configure TCP/IP settings accordingly and join to the domain * Promote CERES to a DC, make it a GC also * Install services like DNS,WINS,DHCP,etc. (if needed) on CERES (or some other more powerfull server) and configure accordingly * As HADES if the most powerfull server leave the FSMO roles on it * Install and/or configure everything else needed * Get a cigar and a beer! ;-)
