Critical Vulnerability in Altiris Deployment Server architecture [Archief]

Bekijk Volledige Versie : Critical Vulnerability in Altiris Deployment Server architecture

Brian Gallagher

21/10/04, 18:45

Subject:
Design flaw in Altiris Deployment Server - Attacker can take over all clients on a network with Admininstrator Rights and Remote Control ability

PRODUCTS AFFECTED:
---------------------------------------------------------------------------------------------

ALTIRIS DEPLOYMENT SERVER - 5.x, 6.x, possibly other versions (untested)
POSSIBLY OTHERS? - I have not worked with any of the other Altiris products, so I do not know if they are vulnerable to this, similar or other possible exploits.

SUMMARY:
---------------------------------------------------------------------------------------------

There is a design flaw in the Deployment Server architecture that could allow an attacker to take complete control over all Altiris clients on a network with relative ease.

The flaw is that the AClient.exe process does not request any authentication from the Deployment server and will happily connect to any Deployment server it finds and give it complete Administrator rights to the machine along with the ability to Remotely
Control it.

This flaw can be exploited via physical or wireless access to the network Deployment Server is on, or remotely through a compromised system anywhere on the network that Altiris Deployment server is on and can potentially give an attacker complete administ
rative access to some or all managed clients.

This can be done with little or no advance knowledge of the network or client configurations prior to the attack, depending on the AClient.exe configuration used.

THREAT MITIGATION:
---------------------------------------------------------------------------------------------

Due to a design flaw in the AClient.exe's lack of a proper authentication system, there is little you can do to prevent these exploits.

The best things you can do to protect yourself until Altiris fixes their product is:

1) DO NOT USE THE "Use TCP/IP Multicast to locate a Deployment Server" OPTION WHEN INSTALLING ACLIENT.EXE. Put in a fixed IP address and Port number when installing the client.

This will make it more difficult for someone to exploit this flaw, as they will have to disable the existing deployment server first, or use some other trick to make the attacker's machine seem like the "real" Deployment server.

2) TURN ON THE "Encrypt Sessions with Server" AND THE "Require Encrypted Sessions with Server" OPTIONS WHEN INSTALLING ACLIENT.EXE.

This will require a client computer to reboot before it can be compromised, which creates an additional barrier of entry to an attacker, and give you more time to react in the event a Rogue Deployment server is detected on the network.

3) TURN ON THE "Remain Connected to the server" OPTION WHEN INSTALLING ACLIENT.EXE.

This will provide less of an opportunity for a client to unknowingly connect to a Rogue Deployment Server by maintaining the connection to the one the client first connected to.

4) DO NOT USE THE “Advertise the server this client is connected to through multicasting” OPTION UNLESS ABSOLUTELY REQUIRED.

This would prevent a rouge deployment server from obtaining an additional compromise vector (the advertising AClient.exe connected to a rogue DS) to new machines to control.

SAMPLE EXPLOITS:
---------------------------------------------------------------------------------------------

PREREQUISITE:

BadGuy gets access to the network either (1) physically, by walking in the door and plugs his laptop into any network jack anywhere in the building or connecting to a wireless network access point inside or outside of the building, or (2) by gaining acces
s to any computer on the network, such as through any variety of cracks, viruses, trojans, stolen password, etc.. For purposes of this discussion, I will assume that he simply walks in the door and plugs in a network cable, though it really makes no diff
erence how he connects in order to exploit this flaw.

SCENARIO ONE: AClient.exe configured to connect to Deployment Server via network broadcast

His laptop is running its own copy of Deployment Server ("DS" from here on) (which is available for a free download online (though it is limited to 10 clients)). When clients are booted up, they will send a broadcast request to the network. If the lapto
p responds faster than the company's "Official" DS ("ODS" from here on) , then the client will connect to it, and BadGuy now has complete control over the client through the AClient service.

Furthermore, if BadGuy can knock the official DS off the network (through any variety of Denial of Service attacks, ARP Poisoning, etc.) it can assume the role of the ODS, with the same IP address even, and take over more clients. Additionally BadGuy can
potentially determine the IP address of the ODS by watching network traffic and seeing the broadcast messages that are sent to the ODS, in order to determine the IP address to attack and assume the role of.

SCENARIO TWO: AClient.exe configured to connect to Deployment Server via direct IP address (for example, IP: 1.2.3.4) or hostname.

Same as above, but BadGuy can redirect clients to his laptop by ARP-Poisoning (which makes the network's switches and routers think that the laptop is the machine they should send connect to for the IP address 1.2.3.4) or by using a Denial of Service atta
ck to knock the ODS offline, and the laptop then starts functioning with the IP address
1.2.3.4.

Again, complete control of all clients is on the network is easily achieved.

SCENARIO THREE: AClient.exe configured to connect to Deployment Server via encrypted connection.

Same as above scenarios except that it will require that a client to reboot (for any reason) before the client can be hijacked. When the client computer reboots, it will request new session keys from the DS, in this case the BadGuy's DS, and will use the
se keys (now provided by BadGuy's DS) to encrypt the session communications.

POSSIBLE FIX (for ALTRIS):
---------------------------------------------------------------------------------------------

The root of this problem is that the AClient does not require any authentication to connect to it. It will happily talk to any DS that it finds.

The AClient must be modified (and therefore the Deployment Server itself) to provide a method of authorizing a DS to talk to AClient, and possibly the vice-versa.

The simplest method of fixing this would be have a password set for each AClient upon installation.

Upon connecting, the client and server would verify that they are talking to an authorized system using standard password-testing methods (ie: don’t send the password to the other system, send a hash of it to prevent spoofing and getting the password that
way). Only after authentication would the client and server be allowed to interact further.

VENDOR NOTIFICATION:
---------------------------------------------------------------------------------------------

Altiris tech support was notified of this problem and sent the details of this vulnerability on Friday, November 21, 2003.

Altiris confirmed the problem and assigned it to a support ticket which was escalated for management attention.

I was informed that it had been scheduled to be fixed in a future release, but they did not provide an ETA or any other details.

Since then no follow-up inquiries to Altiris have been responded to.

Since it has been nearly a year, with three new versions (6.0, 6.1, 6.1sp1) and it still does not appear to have been resolved, I am publishing this alert to inform systems administrators of the vulnerability to their networks.

ANALYST INFORMATION:
---------------------------------------------------------------------------------------------
Brian Gallagher - DiamondSea.com - brian@diamondsea.com
We Make E-Commerce Easy - No Technical Experience Required
Consulting - E-Commerce - Web Site Design - Custom Programming
http://www.DiamondSea.com - Toll-Free: 800-604-1476 - Fax: 888-411-8144

KF_lists

22/10/04, 06:35

Altiris seems to have a wonderful track record for responding to
security threats. They pretty much blew me off too.

Anyone using Altiris Remote Control software, be aware that any user can
take SYSTEM privs from the nice tray icon.

I reported the hole to them over a year ago and I doubt they did
anything about it.
-KF

Brian Gallagher wrote:
>
> Subject:
> Design flaw in Altiris Deployment Server - Attacker can take over all clients on a network with Admininstrator Rights and Remote Control ability
>
>
> PRODUCTS AFFECTED:
> ---------------------------------------------------------------------------------------------
>
> ALTIRIS DEPLOYMENT SERVER - 5.x, 6.x, possibly other versions (untested)
> POSSIBLY OTHERS? - I have not worked with any of the other Altiris products, so I do not know if they are vulnerable to this, similar or other possible exploits.
>
>
> SUMMARY:
> ---------------------------------------------------------------------------------------------
>
> There is a design flaw in the Deployment Server architecture that could allow an attacker to take complete control over all Altiris clients on a network with relative ease.
>
> The flaw is that the AClient.exe process does not request any authentication from the Deployment server and will happily connect to any Deployment server it finds and give it complete Administrator rights to the machine along with the ability to Remotel
y Control it.
>
> This flaw can be exploited via physical or wireless access to the network Deployment Server is on, or remotely through a compromised system anywhere on the network that Altiris Deployment server is on and can potentially give an attacker complete admini
strative access to some or all managed clients.
>
> This can be done with little or no advance knowledge of the network or client configurations prior to the attack, depending on the AClient.exe configuration used.
>
>
> THREAT MITIGATION:
> ---------------------------------------------------------------------------------------------
>
> Due to a design flaw in the AClient.exe's lack of a proper authentication system, there is little you can do to prevent these exploits.
>
> The best things you can do to protect yourself until Altiris fixes their product is:
>
> 1) DO NOT USE THE "Use TCP/IP Multicast to locate a Deployment Server" OPTION WHEN INSTALLING ACLIENT.EXE. Put in a fixed IP address and Port number when installing the client.
>
> This will make it more difficult for someone to exploit this flaw, as they will have to disable the existing deployment server first, or use some other trick to make the attacker's machine seem like the "real" Deployment server.
>
> 2) TURN ON THE "Encrypt Sessions with Server" AND THE "Require Encrypted Sessions with Server" OPTIONS WHEN INSTALLING ACLIENT.EXE.
>
> This will require a client computer to reboot before it can be compromised, which creates an additional barrier of entry to an attacker, and give you more time to react in the event a Rogue Deployment server is detected on the network.
>
> 3) TURN ON THE "Remain Connected to the server" OPTION WHEN INSTALLING ACLIENT.EXE.
>
> This will provide less of an opportunity for a client to unknowingly connect to a Rogue Deployment Server by maintaining the connection to the one the client first connected to.
>
> 4) DO NOT USE THE “Advertise the server this client is connected to through multicasting” OPTION UNLESS ABSOLUTELY REQUIRED.
>
> This would prevent a rouge deployment server from obtaining an additional compromise vector (the advertising AClient.exe connected to a rogue DS) to new machines to control.
>
>
> SAMPLE EXPLOITS:
> ---------------------------------------------------------------------------------------------
>
> PREREQUISITE:
>
> BadGuy gets access to the network either (1) physically, by walking in the door and plugs his laptop into any network jack anywhere in the building or connecting to a wireless network access point inside or outside of the building, or (2) by gaining acc
ess to any computer on the network, such as through any variety of cracks, viruses, trojans, stolen password, etc.. For purposes of this discussion, I will assume that he simply walks in the door and plugs in a network cable, though it really makes no di
fference how he connects in order to exploit this flaw.
>
> SCENARIO ONE: AClient.exe configured to connect to Deployment Server via network broadcast
>
> His laptop is running its own copy of Deployment Server ("DS" from here on) (which is available for a free download online (though it is limited to 10 clients)). When clients are booted up, they will send a broadcast request to the network. If the lap
top responds faster than the company's "Official" DS ("ODS" from here on) , then the client will connect to it, and BadGuy now has complete control over the client through the AClient service.
>
> Furthermore, if BadGuy can knock the official DS off the network (through any variety of Denial of Service attacks, ARP Poisoning, etc.) it can assume the role of the ODS, with the same IP address even, and take over more clients. Additionally BadGuy c
an potentially determine the IP address of the ODS by watching network traffic and seeing the broadcast messages that are sent to the ODS, in order to determine the IP address to attack and assume the role of.
>
> SCENARIO TWO: AClient.exe configured to connect to Deployment Server via direct IP address (for example, IP: 1.2.3.4) or hostname.
>
> Same as above, but BadGuy can redirect clients to his laptop by ARP-Poisoning (which makes the network's switches and routers think that the laptop is the machine they should send connect to for the IP address 1.2.3.4) or by using a Denial of Service at
tack to knock the ODS offline, and the laptop then starts functioning with the IP address
> 1.2.3.4.
>
> Again, complete control of all clients is on the network is easily achieved.
>
> SCENARIO THREE: AClient.exe configured to connect to Deployment Server via encrypted connection.
>
> Same as above scenarios except that it will require that a client to reboot (for any reason) before the client can be hijacked. When the client computer reboots, it will request new session keys from the DS, in this case the BadGuy's DS, and will use t
hese keys (now provided by BadGuy's DS) to encrypt the session communications.
>
>
> POSSIBLE FIX (for ALTRIS):
> ---------------------------------------------------------------------------------------------
>
> The root of this problem is that the AClient does not require any authentication to connect to it. It will happily talk to any DS that it finds.
>
> The AClient must be modified (and therefore the Deployment Server itself) to provide a method of authorizing a DS to talk to AClient, and possibly the vice-versa.
>
> The simplest method of fixing this would be have a password set for each AClient upon installation.
>
> Upon connecting, the client and server would verify that they are talking to an authorized system using standard password-testing methods (ie: don’t send the password to the other system, send a hash of it to prevent spoofing and getting the password th
at way). Only after authentication would the client and server be allowed to interact further.
>
>
> VENDOR NOTIFICATION:
> ---------------------------------------------------------------------------------------------
>
> Altiris tech support was notified of this problem and sent the details of this vulnerability on Friday, November 21, 2003.
>
> Altiris confirmed the problem and assigned it to a support ticket which was escalated for management attention.
>
> I was informed that it had been scheduled to be fixed in a future release, but they did not provide an ETA or any other details.
>
> Since then no follow-up inquiries to Altiris have been responded to.
>
> Since it has been nearly a year, with three new versions (6.0, 6.1, 6.1sp1) and it still does not appear to have been resolved, I am publishing this alert to inform systems administrators of the vulnerability to their networks.
>
>
> ANALYST INFORMATION:
> ---------------------------------------------------------------------------------------------
> Brian Gallagher - DiamondSea.com - brian@diamondsea.com
> We Make E-Commerce Easy - No Technical Experience Required
> Consulting - E-Commerce - Web Site Design - Custom Programming
> http://www.DiamondSea.com - Toll-Free: 800-604-1476 - Fax: 888-411-8144
>
>

Brooks, Shane

26/10/04, 05:45

This is the response we received from Altiris when we submitted this =
issue to their people - please respond with your comments/thoughts:

<snip>
Subject:=20

Design flaw in Altiris Deployment Server - Attacker can take over all =
clients on a network with Admininstrator Rights and Remote Control =
ability
</snip>



PRODUCTS AFFECTED:

-------------------------------------------------------------------------=
--------------------

ALTIRIS DEPLOYMENT SERVER - 5.x, 6.x, possibly other versions (untested)

POSSIBLY OTHERS? - I have not worked with any of the other Altiris =
products, so I do not know if they are vulnerable to this, similar or =
other possible exploits.

SUMMARY:

-------------------------------------------------------------------------=
--------------------

There is a design flaw in the Deployment Server architecture that could =
allow an attacker to take complete control over all Altiris clients on a =
network with relative ease.

The flaw is that the AClient.exe process does not request any =
authentication from the Deployment server and will happily connect to =
any Deployment server it finds and give it complete Administrator rights =
to the machine along with the ability to Remotely Control it.

This flaw can be exploited via physical or wireless access to the =
network Deployment Server is on, or remotely through a compromised =
system anywhere on the network that Altiris Deployment server is on and =
can potentially give an attacker complete administrative access to some =
or all managed clients.

This can be done with little or no advance knowledge of the network or =
client configurations prior to the attack, depending on the AClient.exe =
configuration used.

THREAT MITIGATION:

-------------------------------------------------------------------------=
--------------------

Due to a design flaw in the AClient.exe's lack of a proper =
authentication system, there is little you can do to prevent these =
exploits.

The best things you can do to protect yourself until Altiris fixes their =
product is:

1) DO NOT USE THE "Use TCP/IP Multicast to locate a Deployment Server" =
OPTION WHEN INSTALLING ACLIENT.EXE. Put in a fixed IP address and Port =
number when installing the client. =20

This will make it more difficult for someone to exploit this flaw, as =
they will have to disable the existing deployment server first, or use =
some other trick to make the attacker's machine seem like the "real" =
Deployment server.

2) TURN ON THE "Encrypt Sessions with Server" AND THE "Require Encrypted =
Sessions with Server" OPTIONS WHEN INSTALLING ACLIENT.EXE. =20

This will require a client computer to reboot before it can be =
compromised, which creates an additional barrier of entry to an =
attacker, and give you more time to react in the event a Rogue =
Deployment server is detected on the network.

3) TURN ON THE "Remain Connected to the server" OPTION WHEN INSTALLING =
ACLIENT.EXE.

This will provide less of an opportunity for a client to unknowingly =
connect to a Rogue Deployment Server by maintaining the connection to =
the one the client first connected to.

4) DO NOT USE THE "Advertise the server this client is connected to =
through multicasting" OPTION UNLESS ABSOLUTELY REQUIRED.

This would prevent a rouge deployment server from obtaining an =
additional compromise vector (the advertising AClient.exe connected to a =
rogue DS) to new machines to control.

SAMPLE EXPLOITS:

-------------------------------------------------------------------------=
--------------------

PREREQUISITE:

BadGuy gets access to the network either (1) physically, by walking in =
the door and plugs his laptop into any network jack anywhere in the =
building or connecting to a wireless network access point inside or =
outside of the building, or (2) by gaining access to any computer on the =
network, such as through any variety of cracks, viruses, trojans, stolen =
password, etc.. For purposes of this discussion, I will assume that he =
simply walks in the door and plugs in a network cable, though it really =
makes no difference how he connects in order to exploit this flaw.

SCENARIO ONE: AClient.exe configured to connect to Deployment Server =
via network broadcast

His laptop is running its own copy of Deployment Server ("DS" from here =
on) (which is available for a free download online (though it is limited =
to 10 clients)). When clients are booted up, they will send a broadcast =
request to the network. If the laptop responds faster than the =
company's "Official" DS ("ODS" from here on) , then the client will =
connect to it, and BadGuy now has complete control over the client =
through the AClient service.

Furthermore, if BadGuy can knock the official DS off the network =
(through any variety of Denial of Service attacks, ARP Poisoning, etc.) =
it can assume the role of the ODS, with the same IP address even, and =
take over more clients. Additionally BadGuy can potentially determine =
the IP address of the ODS by watching network traffic and seeing the =
broadcast messages that are sent to the ODS, in order to determine the =
IP address to attack and assume the role of.

SCENARIO TWO: AClient.exe configured to connect to Deployment Server =
via direct IP address (for example, IP: 1.2.3.4) or hostname.

Same as above, but BadGuy can redirect clients to his laptop by =
ARP-Poisoning (which makes the network's switches and routers think that =
the laptop is the machine they should send connect to for the IP address =
1.2.3.4) or by using a Denial of Service attack to knock the ODS =
offline, and the laptop then starts functioning with the IP address

1.2.3.4.

Again, complete control of all clients is on the network is easily =
achieved.

SCENARIO THREE: AClient.exe configured to connect to Deployment Server =
via encrypted connection.

Same as above scenarios except that it will require that a client to =
reboot (for any reason) before the client can be hijacked. When the =
client computer reboots, it will request new session keys from the DS, =
in this case the BadGuy's DS, and will use these keys (now provided by =
BadGuy's DS) to encrypt the session communications.

POSSIBLE FIX (for ALTRIS):

-------------------------------------------------------------------------=
--------------------

The root of this problem is that the AClient does not require any =
authentication to connect to it. It will happily talk to any DS that it =
finds.

The AClient must be modified (and therefore the Deployment Server =
itself) to provide a method of authorizing a DS to talk to AClient, and =
possibly the vice-versa.

The simplest method of fixing this would be have a password set for each =
AClient upon installation.

Upon connecting, the client and server would verify that they are =
talking to an authorized system using standard password-testing methods =
(ie: don't send the password to the other system, send a hash of it to =
prevent spoofing and getting the password that way). Only after =
authentication would the client and server be allowed to interact =
further.

VENDOR NOTIFICATION:

-------------------------------------------------------------------------=
--------------------

Altiris tech support was notified of this problem and sent the details =
of this vulnerability on Friday, November 21, 2003.

Altiris confirmed the problem and assigned it to a support ticket which =
was escalated for management attention.

I was informed that it had been scheduled to be fixed in a future =
release, but they did not provide an ETA or any other details.

Since then no follow-up inquiries to Altiris have been responded to.

Since it has been nearly a year, with three new versions (6.0, 6.1, =
6.1sp1) and it still does not appear to have been resolved, I am =
publishing this alert to inform systems administrators of the =
vulnerability to their networks.

ANALYST INFORMATION:

-------------------------------------------------------------------------=
--------------------=20

Brian Gallagher - DiamondSea.com - brian@diamondsea.com

We Make E-Commerce Easy - No Technical Experience Required

Consulting - E-Commerce - Web Site Design - Custom Programming

http://www.DiamondSea.com - Toll-Free: 800-604-1476 - Fax: 888-411-8144

__________________________________________________ _______

The information contained in this message is privileged, confidential =
and=20
intended only for use of the individual or entity addressed above. If =
you=20
have received this communication in error, please immediately notify us
by reply and delete the same. Thank you.=20

Brian Gallagher

01/11/04, 22:55

In-Reply-To: <771B638360252E4E8C31ED28FBA45803030855@OLCCEX01>

Greetings,

(I tried posting this to the list last week but it didn't seem to make it so I'm posting it again.)

Let me say up front that I actually like this product. I want to use it with my own clients, but I need to get this problem fixed before I can recommend it in good conscience to my customers.

One reason I posted this was because I WANT them to fix it so I can sell it to my people and use it. The other reason is that they have an installed base of thousands of organizations, including many governmental agencies, and I don't want people to be a
ble to compromise government networks this easily. Heck, I even emailed a couple govt agencies (even the FBI) trying to figure out the best way to report this safely, and got nowhere. Only after failing all the normal routes of
notification did I post it here.

My detailed responses are inline, below.

Brooks, Shane wrote:

>This is the response we received from Altiris when we submitted this issue to their people - please respond with your comments/thoughts:
>
>Deployment Solution allows any managed client computer to attach to the nearest Deployment Server within a secure environment,

That's their "official loophole" right there that they are trying to use, "within a secure environment".

I'm still waiting for anyone to demonstrate a "secure environment" on an Internet-accessable TCP/IP network with normal human users and modern operating systems. The Bugtraq and Full-Disclosure lists are pretty convincing evidence that there isn't one.

If having "a secure TCP/IP network environment with a connection to the Internet" is a pre-requisite to using their product, almost nobody will ever qualify to use it.

>while also providing options to secure the communication of Deployment Server to its Deployment Agent (commonly called AClient) using multiple security safeguards.

Yes, they have multiple security safeguards, but they are missing the most important one: Authentication. Without this missing piece, the rest of the security safeguards are effectively useless.

>No critical vulnerabilities exist in the Altiris Deployment Server architecture as suggested in the "Critical Vulnerability in Altiris Deployment Server Architecture" article.

I thought I demonstrated that there were vulnerablities pretty well, with a variety of easily demonstrable exploits bypassing each one of their security safeguards.

But since they are unconvinced, here's another one that will let you compromise any computer running AClient on it if you have physical access to it. Note that this is a fairly common situation and can be done in any college campus computer lab, or at th
e desk of somebody in an office when they go to the bathroom.

Take a laptop with Deployment Server installed and a cross-over network cable and plug the other end of the cable into the target PC's network jack.

You can now do any of the original exploits detailed in the first post and root their machine before they notice. Worst case, you can reboot their computer by pulling the plug and letting it reboot, at which point your laptop will provide it the new encr
yption keys. If you need to bypass the IP checking feature of AClient, run Ethereal on your laptop, see what IP the machine is trying to connect to, and change your laptop to be that IP.

Done. You've rooted their box without ever even having to try to logging into it. Install a back door (via your rogue DS, just to make it fast, easy and ironic) and you now have a point of entry for attacking the rest of their network of computers when
you leave. Worst case, the person notices their machine rebooted and is at the login screen without reason to suspect anything beyond that.

>Basics of Deployment Server-to-AClient Communication
>Altiris Deployment Solution provides two basic ways to connect from the AClient on managed computers to a managing Deployment Server:
>
>1. Use TCP/IP multicast to locate a Deployment Server, or
>
>2. Use TCP/IP to connect to a specific Deployment Server identified by name or IP address.
>
>The first option, Use TCP/IP multicast to locate a Deployment Server, is the default option. Using this setting, AClient will connect to the first Deployment Server it finds on the network subnet. This is a distinct advantage in a secure network in order
to easily allow client computers to attach to the nearest Deployment Server. It is true that if the multicast option is used on an unsecured network, anyone with access to that network can manage client computers by setting up an intercepting Deployment
Server and connecting to and managing all incoming client traffic. For this reason, the multicasting option should only be used within a secure LAN where any rogue Deployment Server would be identified immediately. The requirement of a secure network is c
ommon to any product that supports multicasting and it does not constitute a security flaw.

Again, this concept of "a secure network" is fantasy. It doesn't exist in any useful fashion. Don't design a product for an environment that doesn't exist. When the default option is a setting that allows all your managed computers to be easily comprom
ised by any computer on the network, something is very wrong.

>The second option, Use TCP/IP to connect to Deployment Solution, allows the system administrator to specify the server name or IP address of the Deployment Server, and the port through which it will communicate. Using this AClient setting, the client com
puter can connect only to the Deployment Server specified by name or IP address.

Unless, you simply "pretend" to be this IP address, through a variety of ways detailed in the original post and here.

>To further secure this setting, the administrator should set the Administrator password on AClient.

The Administrator password only keeps the computer user from changing the settings on the AClient on that computer. This password has absolutely nothing to do with authenticating the server or the client to
each other.

It is possible that they added this feature in the new versions and I missed it, in which case I will applaud Altiris and start using their product myself. If this is the case, please let me know where this setting is changed and I will happily make a re
traction/correction post.

>With these settings in place, the managed client computer will only connect to the specified Deployment Server. For example, in the dialog below AClient properties are set to use TCP/IP to connect to the server named osrhgap312ka on Port 402. With the ad
ministrator password set and by specifying the IP address of the legitimate Deployment Server, it is not possible to set up a rogue Deployment Server.

Unless the Administrator password has been changed as I mentioned in the lines above, it is still possible to set up a rogue Deployment Server, as described in this and other posts.

>Altiris has added certificate communication between AClient and Deployment Server and will release this enhancement in the next version of Deployment Solution.

Great! That will make it an even better product, and I applaud Altiris for their progress. But they need to fix their basic implementation first for their installed base.

- Brian

--
Brian Gallagher - DiamondSea.com - brian@diamondsea.com
We Make E-Commerce Easy - No Technical Experience Required
Consulting - E-Commerce - Web Site Design - Custom Programming
http://www.DiamondSea.com - Toll-Free: 800-604-1476 - Fax: 888-411-8144