Ghost Solution Suite

Hi folks

 

Hope somebody can shed some light on the problem I am facing. 

 

I have the following Szenario:

 

- We use GSS 2.5 in our Active Directory/Domain environment for deployment and it works fine.

  (Let's call it AD/Domain 1)

 

- We have set up a new Active Directory/Domain for training purposes.

  (Let's call it AD/Domain 2)

 

This new domain is not trusted to the existing AD in any way (and must not be; because of security).

The new AD/Domain 2 stays on the same network and in the same IP range as AD/Domain 1.

So basically from TCP/IP perspective they can see each other.

 

My question:

 

Is it possible to use the existing Ghost Console in AD/Domain 1 to manage (create, deploy, ..) images/PCs in AD/Domain 2 ?

 

I see there is the Supported Domain List configuration dialog and I can add Domain 2 there. But it seems that there exists only one common Console Service Account for all the listed domains.

 

But I would need a specific console service account for AD/Domain 2.

 

So the Service console located in AD/Domain 1 would need to use this specific account to manage computer accounts in AD/Domain 2. I would prefer a single Ghost Server responsible for all my ADs/Domains.

 

Is this possible or do I have to install GSS 2.5 in the AD/Domain 2 separately to get this done.

 

As the Ghost Agent installed on all PCs is a simple TCP/IP based agent (not related to AD, etc. ) I had the feeling this should be possible. But as the Console Service manages computer accounts, OU Membership, etc. I am not so sure if this is possible.

 

If it is not possible why does GSS offer the Supported Domain List dialog ? For trusted domains only ?

 

Hope somebody can help me with this.

 

With Kind regards

Oliver

 

 

A clarification for you:

---

exists only one common Console Service Account for all the listed domains

---

An important distinction to bear in mind is the difference between an account, which is a specific object in a security domain, and the credentials (a username and password) used to access an account.

For various historical reasons (the GSS console and client system has been a part of the Ghost product for about 10 years now) we've always used a single set of credentials to represent a single GSS console on whatever domains you wish the console to manage.

When connecting to a domain or specific domain controller, that name and password are what the console presents as credentials, and usually that means that you want an account on each domain that will accept those credentials.

You don't need any form of trust relationships between the different domains, as long as each domain has its own account object which accepts those credentials.

[ Now, at some point in future we may change this aspect of the console, largely to deal with the practical matter of AD admins who rather than using subdomains and trust relationships so that the AD forest is shaped in the natural way for their network, are instead putting the burden for this onto OUs and ACLs instead (so that only specific account objects in particular source OUs can have permission to manage computer account objects in other OUs) and thus requiring different credential sets even to manage different OUs within a single domain. However, because of the need to redesign several aspects of the UI completely to support custom credential sets for every single potential target OU, it's not a small change. ]

Thank you for the answer

 

In the meantime I found out, that when adding an additional domain and specifying an account with enough rights (domain admin) in the target domain the service account is automatically created in the NEW domain. That works for me. THe sad thing is that this is not clearly explained in the implementation guide.

 

BTW, another question. Is there any way to report back suggestions/features requests for GSS 2.5 ?

I mean to the developer team for further implementation.

 

I think of things such as:

 

- automatically refresh the Log view/window of a task so one does not have to close and re-open the log 

  of a running task to get up to date what happens.

 

- Drag and Drop of objects in the console application instead of cut/copy and paste

 

- The possibility of using the name specified on the computer object for NETBIOS name in the

   configuration ? (e.g. %MACHINENAME%)

 

Where can I bring in such feature requests ?

 

With kind regards,

Oliver

 

---

I mean to the developer team for further implementation.

---

Posting here. The employees who post on this forum aren't support staff, we're the developers and QA team in New Zealand who make the product.

In particular, Krish Jayaratne is the QA manager, and he the folks on his QA team take care of most of the feature suggestions posted here and helps prioritize them. From time to time he does make specific sticky suggestion threads, but in general a post with something like "feature request" in the title is the best way to get noticed in the forum RSS feed.

Hmmm.... Still have some problems with this multiple domain configuration.

 

1) Computer accounts int the target domain are created.

    They are created in "Computers" rather than in my specified OU (Prod/Training/Computers/Clients)

 

    Ghost gives the following WARNING:

 

    Details for: Create machine account    The destination container name cannot be converted to Active Directory form.    The default Active Directory container will be used instead.     Prod/Training/Computers/Clients     PIN1213019, SIN00002

 

 

2) Later in the process when joining the domain it gives another WARNING:

 

 

Details for: ConfigurationFailed to join domain: The filename, directory name, or volume label syntax is incorrect.

 

 

Especially case 2) is bad as the machines don't join the domain.

 

 

Some additional information. The Ghost Console (Server) doesn't have the same DNS servers

as the I-Training domain. But the clients in the I-Training domain get the correct DNS server

IP address and domainname for the I-Training Domain assigned by DHCP. So the clients correctly

point to the I-Training Active Directory.

 

On the Ghost Service console I had to create an LMHOSTS entry

 

a.b.c.d   SIN00002  #PRE #DOM:I-TRAINING

 

so that the Ghost Console knows how to locate the I-TRAINING domain controller.

 

I am not sure if my setup creates a problem but fact is that Ghost agent(s) on my Windows XP

client(s) cannot join the I-TRAINING domain even with correct DNS server IP and domain name.

 

If join them manually it works just fine.

 

So what is going wrong here ? Why can the agent not join them to the domain ?

 

Regards,

Oliver

 

---

The Ghost Console (Server) doesn't have the same DNS servers as the I-Training domain.

---

That's likely to cause problems. Active Directory, and everything related to it (including the Microsoft-provide API sets that we need to use to work with AD), is extremely sensitive to DNS configuration.

Just as background, the way the GSS console has always done domain joining is by having the server precreate the domain account for the client machine, and then asks the client to complete it. The point of doing things this way is that it means that the GSS server never exposes any administrative-level account credentials to the client machines.

[ Remember that when you manually join a machine to a domain, you're entering highly powerful account credentials into a client machine. That's fine when you're sitting at it because you as a human administrator are making a very important trust decision about the machine when you choose to type that sensitive data into it.

For something that automates this process like GSS, spraying around credentials around networks in plain text would be a really, really bad idea. Although we would like to let the clients do the joining because Microsoft are in effect starting to mandate that things work that way, in order for that process to be safe we have to carefully build up a system where the GSS console requires the clients to prove their identity to it, in addition to the way that the clients require the console to prove its identity to them. ]

So as a result, the console machine current needs to work with the domain controllers to preconstruct the account for the clients, and it is unfortunately the case that it also means that the console machine requires access to the appropriate DNS entries used behind the scenes by the Active Directory system. Otherwise, the APIs we call to do the work simply don't work.

Now, the innards of DNS configuration for Active Directory is a topic that would cover a book by itself, but short of that (assuming you're using the default Active Directory integrated DNS server support in each domain) the simplest thing you should try is giving your console machine access to the DNS servers for both domains.

For Windows XP and 2003, if you examine the GSS server's network connection properties in the control panel, for a network connection the "Internet Protocol (TCP/IP)" item has the properties for DNS. Open the properties for that item, and you can manually configure multiple DNS servers so that one machine is willing to consult the DNS server in both domains. This way, when the GSS server tries to manipulate the secondary domain, all the DNS entries that need to be in place are visible to the machine and the API calls it makes should hopefully start working.

Hello Nigel

 

Thank you for your quick answer. I came to the same conclusion as you that DNS is involved. 

---

Nigel Bree wrote:

For Windows XP and 2003, if you examine the GSS server's network connection properties in the control panel, for a network connection the "Internet Protocol (TCP/IP)" item has the properties for DNS. Open the properties for that item, and you can manually configure multiple DNS servers so that one machine is willing to consult the DNS server in both domains. This way, when the GSS server tries to manipulate the secondary domain, all the DNS entries that need to be in place are visible to the machine and the API calls it makes should hopefully start working.

---

Hmm... Don't like this setup very much as I think it would only work if the GSS server (2003) would

accidentially query the second DNS server.

 

The setup at our university is the following:

 

Main Active Directory uses non-AD integrated DNS but Vital QIP (from Lucent) instead (Yeah... Nasty but it works fine). This is where my GSS server is located and works fine for my current workstations.

 

The i-training.local domain has is a single Domain Controller/File Server (collapsed) Active Directory with 19 training workstations. So it has AD-Integrated DNS. In addition it has defined the university DNS servers (QIP) as forwarders. So the i-training.local AD can see the university AD (DNS) but not the other way round. The university AD (where GSS server is joined) cannot see the i-training.local AD.

 

It is complicate to request forwarders from the university IT department to my i-training.local DC server and maybe they would refuse doing it.

 

Therefore I am looking for a way to tell my GSS server (2003) to forward queries for i-training.local

directly.

 

I added an entry to the local c:\windows\system32\drivers\etc\hosts

 

a.b.c.d    i-training.local

 

But I think it doesn't solve the problem. At least I can still not browse for an OU in the configuration set dialog. It tells me that it cannot reach the AD and that I should enter the OU path manually.

 

I am looking for a way to tell the DNS Client on the 2003 server to forward queries for i-training.local to the AD controller of i-training.local.

 

Any idea ?

 

Regards,

Oliver

 

Found a solution....

 

Installed a MS DNS Server on my GSS Server as caching only DNS. My GSS Servers network configuration points to itself (127.0.0.1) and the caching DNS forwards everything to the University DNS servers.

 

An exception forwarding rule redirects DNS queries for i-training.local to my Training AD Controller. Simple and rocks like a charm. GSS works fine as well. Computer accounts are created in the correct location (OU). No more warnings.

 

Thanks for helping Nigel

 

Regards,

Oliver

 

PS. Did you see my GSS 2.5 Feature Requests ?

 

Thanks for posting that solution, it's a good one. I was trying to think of something you could do, since there really isn't any way to configure the Microsoft TCP/IP stack to override that (at least, that I know of) and your solution is a really good one since it doesn't require anything external to the machine.

The key problem here is that AD's dependence on DNS isn't anything specific to what we're doing, or particularly specific to the implementations of the APIs that we need to call either - Active Directory is sensitive to DNS in several ways, not just in terms of looking up IP address for names or domain controller names in domains via SRV records, but also because of the important role that DNS plays with respect to Service Principal Names in the Kerberos security infrastructure.

[ Incidentally, while doing some background reading I came across this helpful article from the Directory Services team which explains how DNS is involved in forming principal and realm names.

Which also reminds me of another great mystery in terms of domain authentication, which is clock skew. Machines really need to have the correct time set in them! See this article about the importance of having machines with the correct time set in them! ]

Thanks for sharing how you solved this!