ExamGecko
Question list
Search
Search

List of questions

Search

Related questions








Refer to the scenario. # Introduction to the customer You are helping a company add Aruba ClearPass to their network, which uses Aruba network infrastructure devices. The company currently has a Windows domain and Windows CA. The Window CA issues certificates to domain computers, domain users, and servers such as domain controllers. An example of a certificate issued by the Windows CA is shown here. The company is in the process of adding Microsoft Endpoint Manager (Intune) to manage its mobile clients. The customer is maintaining the on-prem AD for now and uses Azure AD Connect to sync with Azure AD. # Requirements for issuing certificates to mobile clients The company wants to use ClearPass Onboard to deploy certificates automatically to mobile clients enrolled in Intune. During this process, Onboard should communicate with Azure AD to validate the clients. High availability should also be provided for this scenario; in other words, clients should be able to get certificates from Subscriber 2 if Subscriber 1 is down. The Intune admins intend to create certificate profiles that include a UPN SAN with the UPN of the user who enrolled the device. # Requirements for authenticating clients The customer requires all types of clients to connect and authenticate on the same corporate SSID. The company wants CPPM to use these authentication methods: EAP-TLS to authenticate users on mobile clients registered in Intune TEAR, with EAP-TLS as the inner method to authenticate Windows domain computers and the users on them To succeed, EAP-TLS (standalone or as a TEAP method) clients must meet these requirements: Their certificate is valid and is not revoked, as validated by OCSP The client's username matches an account in AD # Requirements for assigning clients to roles After authentication, the customer wants the CPPM to assign clients to ClearPass roles based on the following rules: Clients with certificates issued by Onboard are assigned the "mobile-onboarded" role Clients that have passed TEAP Method 1 are assigned the "domain-computer" role Clients in the AD group "Medical" are assigned the "medical-staff" role Clients in the AD group "Reception" are assigned to the "reception-staff" role The customer requires CPPM to assign authenticated clients to AOS firewall roles as follows: Assign medical staff on mobile-onboarded clients to the "medical-mobile" firewall role Assign other mobile-onboarded clients to the "mobile-other" firewall role Assign medical staff on domain computers to the "medical-domain" firewall role All reception staff on domain computers to the "reception-domain" firewall role All domain computers with no valid user logged in to the "computer-only" firewall role Deny other clients access # Other requirements Communications between ClearPass servers and on-prem AD domain controllers must be encrypted. # Network topology For the network infrastructure, this customer has Aruba APs and Aruba gateways, which are managed by Central. APs use tunneled WLANs, which tunnel traffic to the gateway cluster. The customer also has AOS-CX switches that are not managed by Central at this point. # ClearPass cluster IP addressing and hostnames A customer's ClearPass cluster has these IP addresses: Publisher = 10.47.47.5 Subscriber 1 = 10.47.47.6 Subscriber 2 = 10.47.47.7 Virtual IP with Subscriber 1 and Subscriber 2 = 10.47.47.8 The customer's DNS server has these entries cp.acnsxtest.com = 10.47.47.5 cps1.acnsxtest.com = 10.47.47.6 cps2.acnsxtest.com = 10.47.47.7 radius.acnsxtest.com = 10.47.47.8 onboard.acnsxtest.com = 10.47.47.8 You have started to create a CA to meet the customer's requirements for issuing certificates to mobile clients, as shown in the exhibit below. What change will help to meet those requirements and the requirements for authenticating clients?



Question 3 - HPE6-A84 discussion

Report
Export

Refer to the scenario.

A customer requires these rights for clients in the "medical-mobile" AOS firewall role on Aruba Mobility Controllers (MCs):

Permitted to receive IP addresses with DHCP

Permitted access to DNS services from 10.8.9.7 and no other server

Permitted access to all subnets in the 10.1.0.0/16 range except denied access to 10.1.12.0/22

Denied access to other 10.0.0.0/8 subnets

Permitted access to the Internet

Denied access to the WLAN for a period of time if they send any SSH traffic

Denied access to the WLAN for a period of time if they send any Telnet traffic

Denied access to all high-risk websites

External devices should not be permitted to initiate sessions with "medical-mobile" clients, only send return traffic.

The exhibits below show the configuration for the role.

There are multiple issues with this configuration. What is one change you must make to meet the scenario requirements? (In the options, rules in a policy are referenced from top to bottom. For example, "medical-mobile" rule 1 is "ipv4 any any svc-dhcp permit," and rule 8 is "ipv4 any any any permit".)

A.
In the "medical-mobile" policy, move rules 2 and 3 between rules 7 and 8.
Answers
A.
In the "medical-mobile" policy, move rules 2 and 3 between rules 7 and 8.
B.
In the "medical-mobile" policy, change the subnet mask in rule 3 to 255.255.248.0.
Answers
B.
In the "medical-mobile" policy, change the subnet mask in rule 3 to 255.255.248.0.
C.
Move the rule in the "apprf-medical-mobile-sacl" policy between rules 7 and 8 in the "medicalmobile" policy.
Answers
C.
Move the rule in the "apprf-medical-mobile-sacl" policy between rules 7 and 8 in the "medicalmobile" policy.
D.
In the "medical-mobile" policy, change the source in rule 8 to "user."
Answers
D.
In the "medical-mobile" policy, change the source in rule 8 to "user."
Suggested answer: B

Explanation:

The subnet mask in rule 3 of the "medical-mobile" policy is currently 255.255.252.0, which means that the rule denies access to the 10.1.12.0/22 subnet as well as the adjacent 10.1.16.0/22 subnet 1.

This is not consistent with the scenario requirements, which state that only the 10.1.12.0/22 subnet should be denied access, while the rest of the 10.1.0.0/16 range should be permitted access.

To fix this issue, the subnet mask in rule 3 should be changed to 255.255.248.0, which means that the rule only denies access to the 10.1.8.0/21 subnet, which includes the 10.1.12.0/22 subnet 1. This way, the rule matches the scenario requirements more precisely.

asked 16/09/2024
Ali Alaqoul
43 questions
User
Your answer:
0 comments
Sorted by

Leave a comment first