Re: [ActiveDir] OT: Vista Activation and KMS
If a Vista KMS client contacts a beta KMS host, the client will receive an invalid version error and will proceed to try another KMS from the list provided by DNS. This is good information, Rich; I hadn't seen this before. It means that beta and production KMS infrastructures can coexist. Thanks for posting. - Harvey On 12/12/06, Rich Milburn [EMAIL PROTECTED] wrote: I got an answer about KMS. I hesitated about posting here but I think this just clears up the misconceptions expressed in the thread, it doesn't really disclose any new information… There are 2 issues here, and a bit of a misunderstanding. Windows Server codenamed Longhorn is still in beta. The KMS service for beta builds will not allow released products to activate. So, if you want to support both Longhorn and the released version of Vista with KMS, you will need 2 KMS hosts. However, when Longhorn is released, any KMS intended to activate Longhorn servers will also activate Vista volume clients. Secondly, the KMS client will retrieve all SRV records from DNS. It will pick one at random and attempt to connect to it. If the client does not successfully activate or renew its activation, it will pick another KMS from the list, and so on until they succeed or they have tried the entire list. If a Vista KMS client contacts a beta KMS host, the client will receive an invalid version error and will proceed to try another KMS from the list provided by DNS. I hope that helps clear things up. *---** **Rich Milburn** **MCSE, Microsoft MVP - Directory Services** Sr Network Analyst, Field Platform Development Applebee's International, Inc.** **4551 W. 107th St** **Overland Park, KS 66207** **913-967-2819** **--** **I love the smell of red herrings in the morning - anonymous* *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Rich Milburn *Sent:* Thursday, December 07, 2006 11:09 AM *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] OT: Vista Activation and KMS My hope was that KMS could support more than one key. I was astonished when I discovered it didn't. If you were Vista, KMS would supply you with a Vista key. Longhorn, a Longhorn key. Since KMS only supports one key, it triggers the need for two separate KMS infrastructures and the problems in #2 below. I put this up in the beta volume licensing group, hopefully there will be some MSFT response on this. I agree with you – the point of making it easy by allowing srv records is offset by the fact neither the VL client nor the KMS server can differentiate between Vista and LHS. Even if the solution is to update the KMS service prior to longhorn's release, and have separate srv records (one for Vista, one for longhorn, another for ?? because you know they're on a roll now and will soon have other things doing VLA) personally I'd rather have multiple records than multiple KMS servers, and hard-coding reg keys or using MAKS for all servers is not really a good solution, IMHO. Rich *--- **Rich Milburn **MCSE, Microsoft MVP - Directory Services Sr Network Analyst, Field Platform Development Applebee's International, Inc.** **4551 W. 107th St** **Overland Park, KS 66207** **913-967-2819** **--** **I love the smell of red herrings in the morning - anonymous* *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Harvey Kamangwitz *Sent:* Tuesday, December 05, 2006 11:41 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] OT: Vista Activation and KMS On 12/5/06, *Laura A. Robinson* [EMAIL PROTECTED] wrote: Inline... -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Harvey Kamangwitz *Sent:* Tuesday, December 05, 2006 11:28 AM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] OT: Vista Activation and KMS If you have any kind of a complex environment, you'll find volume activation to be very frustrating indeed: 1. The KMS service can't support more than one key, so if you have Longhorn VL clients in your environment you have to put up a second KMS infrastructure for them. Actually, when you purchase a KMS key, you get to activate TWO KMS hosts with that key, up to ten times each. Therefore, you don't have to put up a second KMS infrastructure. From a subsequent post on this thread: Doh! Okay, now I think I get what you're referencing in item 1. There's a reason for that- LH isn't out yet. When LH is out, that won't be an issue. :-) My hope was that KMS could support more than one key. I was astonished when I discovered it didn't. If you were Vista, KMS would supply you with a Vista key. Longhorn, a Longhorn key. Since KMS only supports one key, it triggers the need
Re: [ActiveDir] OT: Vista Activation and KMS
Oops. I forgot a few words: ...can coexist *using autodiscovery.* ** -H On 12/12/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: If a Vista KMS client contacts a beta KMS host, the client will receive an invalid version error and will proceed to try another KMS from the list provided by DNS. This is good information, Rich; I hadn't seen this before. It means that beta and production KMS infrastructures can coexist. Thanks for posting. - Harvey On 12/12/06, Rich Milburn [EMAIL PROTECTED] wrote: I got an answer about KMS. I hesitated about posting here but I think this just clears up the misconceptions expressed in the thread, it doesn't really disclose any new information… There are 2 issues here, and a bit of a misunderstanding. Windows Server codenamed Longhorn is still in beta. The KMS service for beta builds will not allow released products to activate. So, if you want to support both Longhorn and the released version of Vista with KMS, you will need 2 KMS hosts. However, when Longhorn is released, any KMS intended to activate Longhorn servers will also activate Vista volume clients. Secondly, the KMS client will retrieve all SRV records from DNS. It will pick one at random and attempt to connect to it. If the client does not successfully activate or renew its activation, it will pick another KMS from the list, and so on until they succeed or they have tried the entire list. If a Vista KMS client contacts a beta KMS host, the client will receive an invalid version error and will proceed to try another KMS from the list provided by DNS. I hope that helps clear things up. *--- ** **Rich Milburn** **MCSE, Microsoft MVP - Directory Services** Sr Network Analyst, Field Platform Development Applebee's International, Inc.** **4551 W. 107th St** **Overland Park, KS 66207** **913-967-2819 ** **-- ** **I love the smell of red herrings in the morning - anonymous* *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Rich Milburn *Sent:* Thursday, December 07, 2006 11:09 AM *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] OT: Vista Activation and KMS My hope was that KMS could support more than one key. I was astonished when I discovered it didn't. If you were Vista, KMS would supply you with a Vista key. Longhorn, a Longhorn key. Since KMS only supports one key, it triggers the need for two separate KMS infrastructures and the problems in #2 below. I put this up in the beta volume licensing group, hopefully there will be some MSFT response on this. I agree with you – the point of making it easy by allowing srv records is offset by the fact neither the VL client nor the KMS server can differentiate between Vista and LHS. Even if the solution is to update the KMS service prior to longhorn's release, and have separate srv records (one for Vista, one for longhorn, another for ?? because you know they're on a roll now and will soon have other things doing VLA) personally I'd rather have multiple records than multiple KMS servers, and hard-coding reg keys or using MAKS for all servers is not really a good solution, IMHO. Rich *--- **Rich Milburn **MCSE, Microsoft MVP - Directory Services Sr Network Analyst, Field Platform Development Applebee's International, Inc.** **4551 W. 107th St** **Overland Park, KS 66207 ** **913-967-2819** **-- ** **I love the smell of red herrings in the morning - anonymous * *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Harvey Kamangwitz *Sent: *Tuesday, December 05, 2006 11:41 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] OT: Vista Activation and KMS On 12/5/06, *Laura A. Robinson* [EMAIL PROTECTED] wrote: Inline... -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Harvey Kamangwitz *Sent:* Tuesday, December 05, 2006 11:28 AM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] OT: Vista Activation and KMS If you have any kind of a complex environment, you'll find volume activation to be very frustrating indeed: 1. The KMS service can't support more than one key, so if you have Longhorn VL clients in your environment you have to put up a second KMS infrastructure for them. Actually, when you purchase a KMS key, you get to activate TWO KMS hosts with that key, up to ten times each. Therefore, you don't have to put up a second KMS infrastructure. From a subsequent post on this thread: Doh! Okay, now I think I get what you're referencing in item 1. There's a reason for that- LH isn't out yet. When LH is out, that won't be an issue. :-) My hope
Re: [ActiveDir] OT: Vista Activation and KMS
If you have any kind of a complex environment, you'll find volume activation to be very frustrating indeed: 1. The KMS service can't support more than one key, so if you have Longhorn VL clients in your environment you have to put up a second KMS infrastructure for them. 2. You can't (rather, shouldn't) use autodiscovery If you do have both LH and Vista. The KMS client can't distinguish between a KMS with LH and a KMS with Vista, and there's nothing in the client that says oh, I hit a KMS but it has the wrong key so try again immediately so ~50% of a client's activation attempts will fail. 3. Autodiscovery isn't practical if you have more than a few forests that don't trust the forest your KMS is in. All admins of the untrusted forests must manually register the _vlmcs record in their forest to find the KMS. ...the list goes on. (I haven't even mentioned the practical aspects of volume activation in a lab or firewalled environment.) It's not a fully-baked solution. Depending on your environment, it might be easier to scrap the whole autodiscovery, create a DNS CNAME with a couple of KMS behind it, stuff the FQDN in the KMS client's registry if you have a standard build, and fugeddaboutit :-). On 12/4/06, Laura A. Robinson [EMAIL PROTECTED] wrote: KMS runs on Vista (now), will run on Longhorn when Longhorn is released, and will also run on Win2K3 as soon as we finish making the Win2K3 install. :-) Laura -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Monday, December 04, 2006 1:12 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] OT: Vista Activation and KMS Nope, I've done it web based. At the present time there are two kinds of keycodes up on MVLS.. one that wants a KMS, the other that will phone home to Redmond automatically. Have your MVLS folks request the other type of key is my understanding how this will work for now. The KMS type won't be out until Longhorn. KMS activations will have to phone home to your servers twice a year. Brian Cline wrote: I was testing out the RTM of Vista Enterprise last night and noticed I didn't have to enter a key at any point during the install. When Windows tried to activate, it told me there was a DNS error, so I suspected it looks for a local activation server by default. Sure enough, in the DNS cache was a lookup for a nonexistent _vlmcs._tcp.domain.com. Upon further research, it appears Microsoft has not released KMS yet, and I couldn't find any option to activate directly with Microsoft. For the moment, is telephone activation the only option? Brian Cline, Applications Developer Department of Information Technology GP Trucking Company, Inc. 803.936.8595 Direct Line 800.922.1147 Toll-Free (x8595) 803.739.1176 Fax -- Letting your vendors set your risk analysis these days? http://www.threatcode.com If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will hunt you down... http://blogs.technet.com/sbs List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.6/567 - Release Date: 12/4/2006 7:18 AM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.6/567 - Release Date: 12/4/2006 7:18 AM List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ -- S.
Re: [ActiveDir] OT: Vista Activation and KMS
On 12/5/06, Laura A. Robinson [EMAIL PROTECTED] wrote: Inline... -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Harvey Kamangwitz *Sent:* Tuesday, December 05, 2006 11:28 AM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] OT: Vista Activation and KMS If you have any kind of a complex environment, you'll find volume activation to be very frustrating indeed: 1. The KMS service can't support more than one key, so if you have Longhorn VL clients in your environment you have to put up a second KMS infrastructure for them. Actually, when you purchase a KMS key, you get to activate TWO KMS hosts with that key, up to ten times each. Therefore, you don't have to put up a second KMS infrastructure. From a subsequent post on this thread: Doh! Okay, now I think I get what you're referencing in item 1. There's a reason for that- LH isn't out yet. When LH is out, that won't be an issue. :-) My hope was that KMS could support more than one key. I was astonished when I discovered it didn't. If you were Vista, KMS would supply you with a Vista key. Longhorn, a Longhorn key. Since KMS only supports one key, it triggers the need for two separate KMS infrastructures and the problems in #2 below. I'm assuming that Microsoft will be using Volume Activation for other products in the future; are we to put up a separate KMS for each? 2. You can't (rather, shouldn't) use autodiscovery If you do have both LH and Vista. The KMS client can't distinguish between a KMS with LH and a KMS with Vista, and there's nothing in the client that says oh, I hit a KMS but it has the wrong key so try again immediately so ~50% of a client's activation attempts will fail. So remove the DNS records for the LH KMS, or am I misunderstanding your point? To be more specific: In a Vista / Longhorn environment, you should only use autodiscovery for one KMS infrastructure because of 50% failure rate above. The other systems (Longhorn, if you choose autodiscovery for Vista) must be explictly pointed to a KMS with slmgr. How much of an adminstrative headache this is depends on how great a penetration of a standard build is in your company; you can code it into the build. 3. Autodiscovery isn't practical if you have more than a few forests that don't trust the forest your KMS is in. All admins of the untrusted forests must manually register the _vlmcs record in their forest to find the KMS. slmgr.vbs. We're not talking about a ton of records here or a difficult population mechanism. It's the logistics and overhead that's a pain. No, the act of registering a _vlmcs record in a domain is not in itself a difficult task; it's the help desk scripts and calls from panicky system administrators when all the clients in their forest start complaining about failure to activate and reduced functionality mode that have to be handled. In a large enterprise we could see a lot of these (everyone that brings up a sandbox forest for application testing, for example). I'm attempting to design a solution that minimizes the impact for everybody - corporate forest administrators, Vista users, help desk, untrusted test forest administrators, etc. ...the list goes on. (I haven't even mentioned the practical aspects of volume activation in a lab or firewalled environment.) I'd be happy to discuss your options around them if you should decide to elaborate further. If the firewalled labs don't want to open port 1688 to find a KMS, they either have to bring up their own KMS or use MAKs. I for one don't want to hand out KMS / volume keys to *anyone *outside the corporate KMS infrastructure. And MAKs, though I haven't studied them as closely, are a pain for labs that rebuild their clients because they're a single-use item (by which I mean that if you use up one activation count on a MAK then rebuild, it increments the MAK count - you can't reuse the previous one). And they still require some kind of internet access, or by proxy, or by phone, to activate them. It's not a fully-baked solution. I would tend to disagree. From a technical standpoint, I think it's pretty well-baked. From a business process standpoint, it's still coming up to speed. Depending on your environment, it might be easier to scrap the whole autodiscovery, create a DNS CNAME with a couple of KMS behind it, stuff the FQDN in the KMS client's registry if you have a standard build, and fugeddaboutit :-). I'm not really understanding your concerns about autodiscovery. Could you be more specific about your environment? - Autodiscovery is no problem for Vista clients in the corporate (account) forest; that's where the KMS service is. - Not much more problem for clients in major (top tier) trusted forests. - Begins to be overhead for corp forest admins when you start adding 2nd and 3rd tier trusted forests into the KMS autodiscovery registry key (who can really keep track of what's active and what's died
Re: [ActiveDir] Security-enable all your distribution lists?
Thanks for the doc, Jorge; I'd missed that in my searches. And my initial reaction was not only no, but hell no! to the request. But when I examine it logically it's harder to reject out of hand. A little while ago, we did change the default for new DL group requests to be security enabled. And it seems to me that one would implicitly assume that if one were setting access to a resource like sharepoint, they would use the same thought process as when they're sending mail: Do I want everyone in this group to get this mail | have this access? - Harvey On 10/21/06, Al Mulnick [EMAIL PROTECTED] wrote: My first reaction is, NOOO don't do that. That's silly. I absolutely abhor the concept of convenience to this level when it comes to access to secured resources. Saying that, DG's are often created by default as a security group. I'd actually be surprised, and I would applaud the person that made that choice in your organization. From my perspective, the worst thing ever done by Microsoft was to allow DG's to be security groups. Made it easier to transition PF's sure, but the layer8 contingent doesn't understand the subtle differences between a distribution list and a security-enabled-distribution-group. This loosely translates into people that want to include somebody on their regular mail lists, but don't want them to necessarily have access to the same data shares. They do NOT understand the difference in most cases. I don't know sharepoint well enough to say, but I would be completely floored if they did not have a way to revert behavior. I also would be totally surprised if your information security people were OK with this concept for the reasons I mentioned above. TokenBloat is not the only concern you have here, Harvey. On 10/20/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint. Setting permissions on Sharepoint sites has always been kind of a pain, partly because of Sharepoint itself but also because of the nature of what you're doing. (DISCLAIMER: I'm nothing more than a just-beyond-basic Sharepoint user.) When you set up a teamsite for a project, you want to enable access to the site to the project people. Typically you use an existing group of people in your org ( e.g. your work group for a weekly meeting site), or you create a new group to manage access. Most work groups have mailing distribution lists, but I'll bet most are not security-enabled. So when you set up your teamsite, you have to wait and ask for IT to security-enable your DL so you can use it on your shiny new teamsite. (Unless you're one of us, in which case you can do it yourself :) In the current version of sharepoint, you can work around this by going to the GAL and manually adding individual users to site access. Apparently the next version of Sharepoint does not allow you to do this, forcing everyone that needs group access to security-enable their group. That's why they want to enable ALL of them, not just piecemeal. Our analysis shows that the MEDIAN number of distribution lists per user is relatively small (5-6) and the MEDIAN number of groups in Joe User's token is relatively small (40-50). But we have lots of users in the 100+ groups range, and the winner for greatest number of groups is 400! So...we have to do what we can to mitigate the impact for the large--token people. Do you folks have any feel for a you really don't want to go beyond there limit on token size? Any direct experience? There's no way we can know all the apps out there that might be affected by this. Thanks, Harvey
Re: [ActiveDir] Forest trust divestitures
Thank you all for your comments. My apologies on the slow response; I was on vacation and I try not to check ActiveDir then :). We did modify our plans to use the interim domain because it provides time ahead of the cutover day to move the resources, doesn't impact the receiving domain with cut-off FSMOs, etc. (BTW, the team nicknamed it the Kamangwitz two-step, but I told them the Guido two-step would be both more accurate and easy to say! But the hand-off issues and the like are there. Our core directory team was going to build the migration domain, it so we knew would be perfect :). And for all that, I just learned that with the Quest consultant onsite, they're going to do a no-trust migration with Migration Manager after all. So all that thrashing for nuthin'. I told the team, I'm trying to keep my distance on this rollercoaster ride - they make me sick. Thanks again, Harvey On 10/11/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I didn't read Harvey's comment "ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back " as something that already exists today. I would have thought is part of his plan and that today there are no DCs from Company B in any of Company A locations. So we're using different assumptions in our discussion – Harvey, can you clarify? Also note Jorge's very valid comment on responsibility: the interims forest C has a clear hand-over of responsibility of the BU being divested. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Wednesday, October 11, 2006 3:12 AM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Forest trust divestitures Agreed that the risk is there. Good idea to spell it out, but I got the sense that much gnashing of teeth was already had over the decision to create a one-way trust or not. And because the dc's already share a network (even though firewalled from time to time) I'm not seeing how the forest C topology helps to mitigate the risk you describe? They'll still have possession of a DC from a previously trusted (and therefore suspect) forest. No difference there. Unless Forest A keeps control of the demilitarized forest C. But then how does Forest B learn to trust them? :) In any event, I see a double migration without much mitigation of risk nor benefit. I'm guessing I'm missing something in the description of the problem else not asking the right question(s). I'm curious if that's the case? If so, is there more information to be aware of in this scenario that can be shared? On 10/10/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: Al, what risk has been assumed? You're assuming everyone understands all the potential risks of binding two AD infrastructures together as suggested, and that we're all playing nice to another? I'm not assuming that. I'm always assuming that there is potential for the bad guys to be around. And if they are, the original plan allows the wrong people (read: Admins of Domain A) to have access to DCs of Domain B. And potentially also the other way around. Not good. Unless merger and we're talking the same company – but that's not the case here – these are two different companies. A firewall doesn't protect from a compromised DC, especially if you bring that DC back into your production forest… /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Tuesday, October 10, 2006 11:44 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Forest trust divestitures curious. I'm not seeing the same things as Guido here. PDC/RID will remain on the forest, but it will be blocked for the duration of the migration while A forest and B forest are not firewalled in that one site. (as I read it). But what makes me curious is this: The risk has already been assumed. What is the advantage here of adding forest C? I see that it's extra steps, but I don't see the connection to the drawn out go-at-your-own-pace migration. I'm interested in having it spelled out for me though. Please. :) On 10/10/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: I certainly wouldn't allow it if I were security either, but they said it was okay. Probably has something to do with the fact the acquisition will almost double the size of the company :). The interim forest is a great idea. I had intended to bring up a test forest to dry-run the migration in company A environment, but I didn't follow the train of thought through to suggest that the actual migration be done to that forest, and moved to the target company. On 10/10/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: If I were the security officer for Company B, I would have real issues with this plan. Most companies with sufficient understanding of AD Security would not want any of their DCs placed in any location where the other company's network is still active (i.e. DCs fr
[ActiveDir] Security-enable all your distribution lists?
Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint. Setting permissions on Sharepoint sites has always been kind of a pain, partly because of Sharepoint itself but also because of the nature of what you're doing. (DISCLAIMER: I'm nothing more than a just-beyond-basic Sharepoint user.) When you set up a teamsite for a project, you want to enable access to the site to the project people. Typically you use an existing group of people in your org ( e.g. your work group for a weekly meeting site), or you create a new group to manage access. Most work groups have mailing distribution lists, but I'll bet most are not security-enabled. So when you set up your teamsite, you have to wait and ask for IT to security-enable your DL so you can use it on your shiny new teamsite. (Unless you're one of us, in which case you can do it yourself :) In the current version of sharepoint, you can work around this by going to the GAL and manually adding individual users to site access. Apparently the next version of Sharepoint does not allow you to do this, forcing everyone that needs group access to security-enable their group. That's why they want to enable ALL of them, not just piecemeal. Our analysis shows that the MEDIAN number of distribution lists per user is relatively small (5-6) and the MEDIAN number of groups in Joe User's token is relatively small (40-50). But we have lots of users in the 100+ groups range, and the winner for greatest number of groups is 400! So...we have to do what we can to mitigate the impact for the large--token people. Do you folks have any feel for a you really don't want to go beyond there limit on token size? Any direct experience? There's no way we can know all the apps out there that might be affected by this. Thanks, Harvey
Re: [ActiveDir] Forest trust divestitures
I certainly wouldn't allow it if I were security either, but they said it was okay. Probably has something to do with the fact the acquisition will almost double the size of the company :). The interim forest is a great idea. I had intended to bring up a test forest to dry-run the migration in company A environment, but I didn't follow the train of thought through to suggest that the actual migration be done to that forest, and moved to the target company. On 10/10/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: If I were the security officer for Company B, I would have real issues with this plan. Most companies with sufficient understanding of AD Security would not want any of their DCs placed in any location where the other company's network is still active (i.e. DCs from company A and company B on same network). That's different in a merger, where the full IT infrastructure will be merged anyways. But you're talking about a divestiture of a PART of a company. The plan you're describing doesn't really scale well over time – not sure if you're considering issues you're experiencing during the migration – how long are you willing to run forest B without PDC/RID etc? What I've done in similar situations is to implement an interims forest. Step 1: implement Interims Forest C in Company A's network migrate objects and resources from divested BU over from Forest A to C. Test that the divested BU works in Forest C and that other Company A Bus continue to work fine as well. Potentially change naming convention of objects to that of Company B during the migration to Forest C. Troubleshoot as necessary. Step2: when ready separate network of Forest C from Company A and integrated it with network from Company B Step3: with sufficient time for planning the integration, migrate objects and resources from Forest C to B. If not done previously, adjust naming of objects convention during this migration. This sounds like a whole lot of extra work, but usually it pays off: it is the most secure way to separate the divested part of the company and doesn't put either company at (unwanted) risks. It also gives you more flexibility on when to do which step and won't cause any issues with either of the operational forests. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Harvey KamangwitzSent: Monday, October 09, 2006 7:58 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Forest trust divestitures Hi all, I'm consulting on a divestiture, and naturally the companies want their respective AD forests to have the minimum amount of contact necessary to migrate the security principals in the divestiture from company A to company B. I wanted to sanity check with this brain trust that we can do a one-wayforest trust in this firewalled situation. (They're going to use Quest Migration Manager for AD, and though technically it doesn't REQUIRE a one-way trust, the Quest SE says it's an order of magnitude easier. A one-way outgoing trust has been approved by the various security players so it can be done.) - ForestA (multiple domains) and ForestB (single domain). In the beginning, no communication between them. - ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back to Company B, so they're healthy.Though they're at Company A, they are firewalled from A until D-day. All forest B pocket network DCs can talk to each other as well as back home. D-Day: - Transfer PDC and RID FSMOs toone of company B'spocket network DCs. (see next step for why.) - Firewall off communication to company B's network, and open up comm to company A's network. This will make for a temporarily unhappy company B forest, but it will be okay for the duration of the migration. More importantly, it'll make the PDC available on the company A network for the forest trust setup and the RID master also available to hand out more RIDs during the migration. There should now be a functional company B forest on company A's network (though it'll be complaining about missing DCs). - Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa. Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs. - Establish the forest trust from A to B. Would selective authentication on the trust protect the visibility of A's security principals? It's mainly designed to protect B's resources from A's users, isn't it? - Do the migration. - Remove the trust - Flip the pocket network firewalls back to block network A and allow network B. - Let replication settle down, then transfer FSMOs back to their original locations. - misc cleanup, like removing conditional forwarding Appreciate any fine-tuning of this scenario, thanks!
[ActiveDir] Forest trust divestitures
Hi all, I'm consulting on a divestiture, and naturally the companies want their respective AD forests to have the minimum amount of contact necessary to migrate the security principals in the divestiture from company A to company B. I wanted to sanity check with this brain trust that we can do a one-wayforest trust in this firewalled situation. (They're going to use Quest Migration Manager for AD, and though technically it doesn't REQUIRE a one-way trust, the Quest SE says it's an order of magnitude easier. A one-way outgoing trust has been approved by the various security players so it can be done.) - ForestA (multiple domains) and ForestB (single domain). In the beginning, no communication between them. - ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back to Company B, so they're healthy.Though they're at Company A, they are firewalled from A until D-day. All forest B pocket network DCs can talk to each other as well as back home. D-Day: - Transfer PDC and RID FSMOs toone of company B'spocket network DCs. (see next step for why.) - Firewall off communication to company B's network, and open up comm to company A's network. This will make for a temporarily unhappy company B forest, but it will be okay for the duration of the migration. More importantly, it'll make the PDC available on the company A network for the forest trust setup and the RID master also available to hand out more RIDs during the migration. There should now be a functional company B forest on company A's network (though it'll be complaining about missing DCs). - Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa. Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs. - Establish the forest trust from A to B. Would selective authentication on the trust protect the visibility of A's security principals? It's mainly designed to protect B's resources from A's users, isn't it? - Do the migration. - Remove the trust - Flip the pocket network firewalls back to block network A and allow network B. - Let replication settle down, then transfer FSMOs back to their original locations. - misc cleanup, like removing conditional forwarding Appreciate any fine-tuning of this scenario, thanks!
Re: [ActiveDir] Forest trust divestitures
Yes, there are several terabytes of server-related resources going with the divestiture and it would be an enormous job to rebuild all the access control from scratch. Sorry, I should have mentioned that. On 10/9/06, Al Mulnick [EMAIL PROTECTED] wrote: I don't think I see what you really want to accomplish? Why, if you're going to firewall the networks off anyway, do you need to migrate vs. Microsoft shuffle (create new on target, delete legacy) ? Are other resources coming with that rely on these? Or are those being migrated as well? Is it just the workstations you're concerned about? If they're part of the same domain, what's the point? Al On 10/9/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: Hi all, I'm consulting on a divestiture, and naturally the companies want their respective AD forests to have the minimum amount of contact necessary to migrate the security principals in the divestiture from company A to company B. I wanted to sanity check with this brain trust that we can do a one-wayforest trust in this firewalled situation. (They're going to use Quest Migration Manager for AD, and though technically it doesn't REQUIRE a one-way trust, the Quest SE says it's an order of magnitude easier. A one-way outgoing trust has been approved by the various security players so it can be done.) - ForestA (multiple domains) and ForestB (single domain). In the beginning, no communication between them. - ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back to Company B, so they're healthy.Though they're at Company A, they are firewalled from A until D-day. All forest B pocket network DCs can talk to each other as well as back home. D-Day: - Transfer PDC and RID FSMOs toone of company B'spocket network DCs. (see next step for why.) - Firewall off communication to company B's network, and open up comm to company A's network. This will make for a temporarily unhappy company B forest, but it will be okay for the duration of the migration. More importantly, it'll make the PDC available on the company A network for the forest trust setup and the RID master also available to hand out more RIDs during the migration. There should now be a functional company B forest on company A's network (though it'll be complaining about missing DCs). - Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa. Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs. - Establish the forest trust from A to B. Would selective authentication on the trust protect the visibility of A's security principals? It's mainly designed to protect B's resources from A's users, isn't it? - Do the migration. - Remove the trust - Flip the pocket network firewalls back to block network A and allow network B. - Let replication settle down, then transfer FSMOs back to their original locations. - misc cleanup, like removing conditional forwarding Appreciate any fine-tuning of this scenario, thanks!
Re: [ActiveDir] Forest trust divestitures
We're going to run a test in the lab in the next few days, then a dry run with the real forest B and a dummy forest B shortly after that. On 10/9/06, Al Mulnick [EMAIL PROTECTED] wrote: So, if I understand correctly you want to migrate the users along with sid-history so that you can also take along a bunch of file servers with it's permissions that are already set for one of the domains in your forest A? When the divestiture occurs, you'll push the user information over. - Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa. Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs.That'll likely be problematic. You'll want to narrow that down more to use specific DC's vs. using any DC. If you use conditional forwarders, the clients of that DNS host (likely itself, but not necessarily) would be able to find B, and the reverse might also be true. The key is to be sure that the dc in A at the particular site and the dc in B at the same site, can see each other. See those links on Microsoft's site that relate to creating a trust over a firewall (but I have to wonder if it's worth it to have a firewall there at all for this). Your biggest risk is that you run into something like sidfiltering or some issue that prevents you from being able to create the trust on schedule and be able to migrate. I suggest you test this scenario and see what shakes out to mitigate the risk that you'll not get it to work on D-Day. As I understand divestitures, they won't be very undrestanding if it's delayed due to an inability to set this up and pull off the migration. Lot's of raw nerves during the MAD process. :) Al On 10/9/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: Yes, there are several terabytes of server-related resources going with the divestiture and it would be an enormous job to rebuild all the access control from scratch. Sorry, I should have mentioned that. On 10/9/06, Al Mulnick [EMAIL PROTECTED] wrote: I don't think I see what you really want to accomplish? Why, if you're going to firewall the networks off anyway, do you need to migrate vs. Microsoft shuffle (create new on target, delete legacy) ? Are other resources coming with that rely on these? Or are those being migrated as well? Is it just the workstations you're concerned about? If they're part of the same domain, what's the point? Al On 10/9/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: Hi all, I'm consulting on a divestiture, and naturally the companies want their respective AD forests to have the minimum amount of contact necessary to migrate the security principals in the divestiture from company A to company B. I wanted to sanity check with this brain trust that we can do a one-wayforest trust in this firewalled situation. (They're going to use Quest Migration Manager for AD, and though technically it doesn't REQUIRE a one-way trust, the Quest SE says it's an order of magnitude easier. A one-way outgoing trust has been approved by the various security players so it can be done.) - ForestA (multiple domains) and ForestB (single domain). In the beginning, no communication between them. - ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back to Company B, so they're healthy.Though they're at Company A, they are firewalled from A until D-day. All forest B pocket network DCs can talk to each other as well as back home. D-Day: - Transfer PDC and RID FSMOs toone of company B'spocket network DCs. (see next step for why.) - Firewall off communication to company B's network, and open up comm to company A's network. This will make for a temporarily unhappy company B forest, but it will be okay for the duration of the migration. More importantly, it'll make the PDC available on the company A network for the forest trust setup and the RID master also available to hand out more RIDs during the migration. There should now be a functional company B forest on company A's network (though it'll be complaining about missing DCs). - Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa. Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs. - Establish the forest trust from A to B. Would selective authentication on the trust protect the visibility of A's security principals? It's mainly designed to protect B's resources from A's users, isn't it? - Do the migration. - Remove the trust - Flip the pocket network firewalls back to block network A and allow network B. - Let replication settle down, then transfer FSMOs back to their original locations. - misc cleanup, like removing conditional forwarding Appreciate any fine-tuning of this scenario, thanks!
