GSS Compatibility with Server 2008 Domain Controllers

Same here, downgrading is not possibility for me.

So no official response on this yet? It's a fairly simple question.

Well pretty simple question this is.

My organization is upgrading to 2008 domain in summer. After that i cannot use ghost. Is there any plans correct this "problem"

Well pretty simple question this is.

No, it's not. Resolving the underlying design problems in the way the APIs provided by Microsoft for client computers to connect to Active Directory domain controllers is not simple at all, which is why it isn't something we have resolved with just a service pack. I shouldn't need to explain to anyone who actually understands the significance of the relevant domain controller policy just what is involved in solving this and therefore why it is nontrivial.

We're definitely aware of the issue; however, it's not yet appropriate for us (as a matter of Symantec corporate policy) to be discussing the specific features in, or potential release dates for, any future releases of GSS in which we may (or may not be) able to perform the necessary redesign work.

Sorry i didn't mean it's technically easy.

I am in position where i cannot admin domain. If i ask domain admin change that policy. Hes answer is "forget ghost and start using sccm". So i hope you understand why i am so nervous from this "problem"

Yup it's our organizations own problem... But i think there is other ghost users who are in same position...

If there is some test work to do for this thing. I am happy to help in it...

Thanks for answering. I only wanted know that this thing is on the "table".

But i think there is other ghost users who are in same position...

Absolutely true, and it's something we do understand; that the folks who need and buy our software often aren't in control of the necessary infrastructure they need to do their jobs - the need for a good network design to be set up to support IP multicast is a classic example, where our customers can be thwarted by network operations staff who just don't know what they are doing.

Of course, it's also the case that some of our customers do know exactly what they are doing, and this means we have to steer quite carefully. Microsoft have, for valid reasons, made their Vista-era releases "secure by default" so that Windows can't be criticised on security grounds. However, what their ratcheting up of this particular setting requires is that we would have to do something much less secure than the way GSS2 works with the Window 2003 default policy setting to work around this - and although we could do that, we won't. A less secure final result is not in anyone's best interests.

The simple fact is that joining a domain is an important security decision. Letting a machine join a domain implies that the identity of the machine is known, and trusted. Microsoft's changes in policy settings, along with the design of the NetJoinDomain API, mean that now that trust has to be demonstrated by giving the end machine the plain-text password of a user account trusted to create a machine account in the domain.

Since giving the plain-text password of an account out to just any machine that asks for it is ... well, madness.... the reality of the problem the GSS console faces is that in order to work around this policy change in Windows 2008 without making customer environments completely insecure, we don't really have any choice except to provide a new UI in which the GSS console in effect has to provide a total replacement for the trust decisions being made when joining a machine to a domain.

In other words, what we have to do to let customers work around this and still have a secure environment is to create some new UI for the GSS console where the GSS console users can explicitly state that they trust a client machine's identity, and we - in this case the royal "we" means me personally - have to then implement a form of cryptographic trust which is secure enough to provide an effective replacement for the Windows 2008 domain trust, so we can join client machines to domains on your behalf.

Now, the bottom line is that we do want to do all this, because it's the right thing to do. The core problem is, though, that it has to be done by giving people tools to make good security decisions, and this is a hard problem. This is why our console in GSS has been doing domain joining in the first place, really - because Windows makes it hard in a mechanical sense for automated processes, and the reason it does this is precisely because of their understanding of the real meaning of domain membership as a security decision. Our aim is to ease the automation aspect, not to weaken security.

Anyway, this is why it's not just a minor bullet-point in a review, or just an inconvenience (as much as we know that it certainly is one to our customers), or "just a bug". Network security is serious, and we do take it seriously just as Microsoft do, and so something half-baked won't do. The simple fact is that this isn't something we can promise until we're very, very sure we have our ducks in a row.

I don't want to be an jerk and repeat my self again and again:(

But just checking if there is any new developments regarding this?

There won't be any change to this until a future GSS3.0 is released; all the work necessary to support this change in how the product works (which is, essentially, to allow clients to be securely authenticated by the GSS servers in the same way clients authenticate the server) was scheduled to be part of that release. Unfortunately, that release has been delayed indefinitely, and there's no information available as to whether that may change - although I would suggest that if you are interested in this, you discuss that with your account manager.

So is symantec thinking over strategy? Continue GSS or just focus in Altiris.
We are currently paying for support. Basically it means we get new versions and we don't need buy new licenses every time major upgrade comes out. Are we paying for nothing?
Too bad if symantec is going to kill GSS. I think it's great and very simple tool. Specially for environments like computer classrooms.

Don't take this a negative way. But as a customer i think my questions are in place. Please relay my message forward for people who answers for these decisions.

Sorry i didn't understand this on. Who do you mean?
"although I would suggest that if you are interested in this, you discuss that with your account manager."

Sorry once again complaining for this. Hopefully i didn't ruin your day:)

Absolutely, as a customer your concerns are valid; however, right now the folks in Symantec's sales division are going to be the most effective method of passing on your concerns to the appropriate level of Symantec management; if your company has a sales account manager at Symantec, talk to them because they can pass your input to the right people. At the present time, that's not something that technical staff like myself who read these forums can be effective at doing on your behalf, as much as we'd like to be able to.