- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
We want to use AMT in our software to support Agent Presence. I have following doubts...
1. What changes we need in our existing software?
2. As we require username & Password for connection, can we store it in a configuration file? Is it the right way to store sensitive information in file? If not What other options are available?
3. Do we need to define policies or individual enterprise will take care of defining policy, registering watchdog and the actions on state change?
4. How can we expose our agent to enterprise? i.e. How the administrator will identify a agent?
Thanks & Regards,
Amit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You've got some pretty interesting questions here Amit.
1. This really depends on your software :). The typical answer is that both a local agent component and management console component need to be involved to use Agent Presence (that's . The console creates the Watchdog on the local AMT system, then passes the unique identifier for that Watchdog to the local agent. At that point, the local agent will register and heartbeat against that Watchdog in AMT. Optionally, a given agent you had could always use the same unique identifier, and the console wouldn't have to pass along the identifier to the local agent. For more details you can refer to the Intel AMT Features > Agent Presence section of the documentation in the SDK.
2. This is more of a general AMT question than just Agent Presence, the question of how to authenticate to AMT. The current answers are either Digest mode (username and password like you mentioned) or Kerberos.In Kerberosthe authentication credentials are in Active Directory (normally), and the authentication is pulled from what user the program is running under (I'm abstracting here, this is a complicated topic). In Digest mode, how the credentials are stored is up to you, but like you said storing them securely is preferable. If they're in a database, typical good practice is that they are stored as a hash as opposed to a clear text password, AMT is capable of accepting a hash for authentication in Digest mode. Well, for the most part, certain usages in older AMT systems can be more complicated. For more on Digest authentication you can look on this section in the SDK: Intel AMT Features > Access Control List Management, for more on Kerberos you can look at theAbout Intel AMT > Integration with Active Directory > Introduction to Kerberos Authentication in the documentation.
3 and 4. The wording of these questionsmakes mehave a question for you. You mention your agent, but you also mention"exposing your agent to the enterprise". Does that mean you are creating a local agent that you want other management solutions towork with, or did I misinterpret you? That's outside the normal use model we're used to (I described this previously), but I would like to hear more details if that's the case.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You've got some pretty interesting questions here Amit.
1. This really depends on your software :). The typical answer is that both a local agent component and management console component need to be involved to use Agent Presence (that's . The console creates the Watchdog on the local AMT system, then passes the unique identifier for that Watchdog to the local agent. At that point, the local agent will register and heartbeat against that Watchdog in AMT. Optionally, a given agent you had could always use the same unique identifier, and the console wouldn't have to pass along the identifier to the local agent. For more details you can refer to the Intel AMT Features > Agent Presence section of the documentation in the SDK.
2. This is more of a general AMT question than just Agent Presence, the question of how to authenticate to AMT. The current answers are either Digest mode (username and password like you mentioned) or Kerberos.In Kerberosthe authentication credentials are in Active Directory (normally), and the authentication is pulled from what user the program is running under (I'm abstracting here, this is a complicated topic). In Digest mode, how the credentials are stored is up to you, but like you said storing them securely is preferable. If they're in a database, typical good practice is that they are stored as a hash as opposed to a clear text password, AMT is capable of accepting a hash for authentication in Digest mode. Well, for the most part, certain usages in older AMT systems can be more complicated. For more on Digest authentication you can look on this section in the SDK: Intel AMT Features > Access Control List Management, for more on Kerberos you can look at theAbout Intel AMT > Integration with Active Directory > Introduction to Kerberos Authentication in the documentation.
3 and 4. The wording of these questionsmakes mehave a question for you. You mention your agent, but you also mention"exposing your agent to the enterprise". Does that mean you are creating a local agent that you want other management solutions towork with, or did I misinterpret you? That's outside the normal use model we're used to (I described this previously), but I would like to hear more details if that's the case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got the answer of question no. 4 in your1st paragraph. Actually I want to kow how enterprise or administrator will identify a agent. So according to you following are the ways...
1. The console creates the Watchdog on the local AMT system, then passes the unique identifier for that Watchdog to the local agent.
2.A given agent youwe canuse the same unique identifier, and the console wouldn't have to pass along the identifier to the local agent.
So in both cases the administrator knows the unique identifier hence he can identify the agent.
But still I have doubt about question no. 3.
Thanks & Regards,
Amit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So it sounds like you might be interested in creating an agent that you want other management consoles to be able to interact with, since you mention the administrator seeing the unique identifier.
Normally, the unique identifier is something that doesn't need to be visible to the administrator, it's built into your solution on bothyour local agent (running on the AMT system) and the your management console (running on the server). There's certainly no reason it couldn't be visible to the administrator, but for the most part that adds complexity without adding much value.
Are you saying you aren't creating the management console software that would interact with the agent, and want other management consoles to be able to use your agent? Like I said, that is outside the normal model. Mainly, I want to make sure I understand why you want the unique identifier to be visible to the administrator.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andrew Schiestl,
My concept was that we have to write a agent which can be watched under a third party console such as commander tool in DTK.
But now I got the idea. We have to write a agent(Client side component), we have to write a Monitor(server side component) which will apply policies and monitor the state of agent. Please reply if I am still wrong.
Thanks & Regards,
Amit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Still, what you mentioned is an interesting idea I hadn't thought about before. It's not strictly speaking impossible to create an agent that could be watched by a third party console, if you created an agent with a hard-coded ID(there is a small possibility of a collision, but the unique ID space is fairly large so it's unlikely). Certainly it would be possible to do this with the DTK, or any other console that allowed the administrator to manually enter the unique identifier.
However, it's important to note that the DTK is a reference design, it's purpose is primarily to act as a reference for creating an actual console (as well as acting as a test tool). Given the complexity of the ID, it's likely that many consoles won't choose to expose this directly to an administrator, in which case there wouldn't be a way for the administrator to start monitoring that agent.
I'll keep this in mind as an idea going forward, thanks for mentioning it!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Javier Andrs Cceres Alvis
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kathy Farrel
ISN Manageability Community Manager
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page