Pass Cisco CCNP Security Certification Exams in First Attempt Easily

Cisco CCNP Security Certification Practice Test Questions, Cisco CCNP Security Exam Practice Test Questions

Want to prepare by using Cisco CCNP Security certification exam practice test questions efficiently. 100% actual Cisco CCNP Security practice test questions and answers, study guide and training course from Exam-Labs provide a complete solution to pass. Cisco CCNP Security exam practice test questions and answers in VCE Format make it convenient to experience the actual test before you take the real exam. Pass with Cisco CCNP Security certification practice test questions and answers with Exam-Labs VCE files.

Introducing Cisco ISE Architecture and Deployment

8. Disable Profiling

In this session, we'll be spending a few moments looking through the IC deployment screens, talking about some of the options and capabilities there. And then we'll disable the IC profiler service so that it's not updating endpoint info until we're better prepared to handle map- or Mac-based authentication. Going into the administration menus, we see Administration System and Deployment. And we can see our single node currently acting in a standalone role, which means all personas and all default services are activated on this particular IC note, and we get a green check box indicating that the node status is helping get some basic information up top. and we can see that we've got different options available. Currently, the role is standalone. You'll notice all the boxes are currently greyed out in terms of disabling or enabling particular functions. And in this case, we'll make it a primary, which specifically means making it a primary pan or policy administration node. And by breaking it into a primary, this will allow us to modify the options. And of course, that would be the first step in a broader deployment where we're applying primary and secondary pans, primary and secondary monitoring, or MNT nodes. And then, of course, multiple individual PFNs are typical for broader distribution. This particular operation, while it takes a few moments to run, does not require a reboot. We see success here. We're currently operating as a primary. Again, it's not immediately indicative—this is the primary plan. Notice that we've got options to be able to modify roles around the monitoring and PSN capabilities of this individual mode, and we can break those out by adding additional notes to the deployment and modifying their capabilities. From the perspective of YSC, it's always aware of all the notes that are part of a particular deployment and the roles that they serve within it. In this case, for the policy service function and policy service persona, we've got different functions that we can enable or disable here. Notice device administration for TAC appserver SXP and thread-centric capabilities. There are also additional options that we can turn on for this particular note here. We'll disable the profiler service, and we'll get a particular pop-up pointing out that we've got a successful update and indicating that services will be restarted. should log us out. what we're seeing here without clicking the OK button in a few minutes. It takes about three or four minutes to review the command line, and we see that the application server is currently in the process of reinitializing this process. To completely reboot or get the application server to a running state, it takes about 10 to 15 minutes within a typical environment. We just took a look at the deployment screens and talked a little bit about how a distributed, resilient, and robust deployment can be managed within. It's a very easy task to accomplish with multiple nodes. And then we disable the profile or service so that it's not adding Mac addresses to our internal data base until we're prepared to do Mac-based authentication via Mac.

9. Certificate Enrollment Part 1

In this session, we'll be doing the first part of certificate enrollment, which obtains a trusted ID cert for use with Ise. As a reminder, there is currently in place a self-signed or self-generated certificate that was created at install with IC. And we're currently seeing the evidence of that by virtue of the trust warning that the Firefox browser is issuing for us: that self signature is being used for other functions in IC. Let's take a look. If we go to administration system and certificates, we can see the default self-signed certificate, and if we open this up and look at the details, we'll see, of course, that it's in use for admin, which governs the administrative web pages that we're using right now, but also governs inter-node communication, where we might have a multiple node deployment. We see also that the self-signed certificate is being used for ePassword, Radius, DTLs, and all the portals that I see that are currently being provided, which would include the guest portals in particular, where we're interacting with end users and end user devices. That trust warning is going to be problematic and not viable for typical production purposes. As a result, we'll need to obtain a trusted ID certificate to use with e-authentication in particular, as well as these portals within the lab. We've got Microsoft Certificate Services active on the domain controller. Let's go ahead and browse into that now. And the first part of establishing a rusted identity certificate is trusting the signer or the signature on that ID certificate. The signer is the certificate authority. The creator of that certificate also places their signature there. We'll need a copy of that signing or CA certificate to validate any received ID certificate, including Isa's own ID certificate, which we're about to create. So we want a copy of the CA certificate first so we can establish that first part of the trust, save this as a file, and then go back over to ISE. Alternatively, we can add two trusted certificates and see that Cisco has placed a dozen or so existing CA signing authorities. These are used for interaction with Cisco's own web pages for the feed and update services that I see needed, as well as other resources on the Internet. So when you import or download the CA cert, browse for that file, and then we'll add a friendly name to distinguish it a little bit from the rest of those trusted certificates. It's already trusted for authentication within ISE. We'll also trust this signer for client authentication and syslog, as well as interaction with Cisco Services and submission. And then we see a copy of our demo to the local CA certificate and some brief information, including the validation period. Okay, now that we've trusted our local CA, now we can obtain an ID certificate for Ise and trust the signature that will be placed there. To start that process off, we need to launch a certificate signing request, and these are pretty similar screens for any entity or device that needs to obtain an ID cert. That ACSR needs to be completed for submission to the CA. In this case, ISE informs us what we can use this ID certificate that we're about to obtain for and some of the certificate authorities that can be applied here. At the drop-down here, we see it's already selected for multiple uses, letting us know that we can utilise a single ID certificate for multiple purposes. If we do the drop-down here, we can see that we can obtain unique ID certs for distinct representations within Ise, including support for ISC to behave as its own certificate authority. Leave that multi-use and we'll check the box to allow use of a wild card certificate. Wildcard certificates in atypical environments are very helpful. One will have multiple nodes, and we want to have a single ID cert representing those multiple nodes. And a typical wildcard certificate has an asterisk for the host part of the FQDN. The common name will be automatically populated by the fully qualified domain name on our node that we're submitting this for, and we'll supply the other information here as well. And these values will be reflected in our final received ID certificate. And as we deliver that to entities that need it, they'll be able to view these fields and confirm other specific information within the ID cert that we'll be utilizing. We'll want to have a variety of subject alternative names.Again, this is to help avoid trust issues and interactions with ISE or multiple nodes within ISE that we're interacting with, so if the name that we're interacting with is also listed as a saying, that will prevent trust issues as well. For use with a wildcard certificate, where that might be in place, it's helpful to mark each node that might be utilising that wildcard card shirt.So we'll represent that here. Typical wild card shirt applications will list the wild card as a sandbox. Another good DNS name to put in is the pointer record or reverse resolve record that would be within DNS. We may be interacting with the node's IP as opposed to a name. And then, to support Microsoft's compatibility issue, if there's interaction with an ethnic group, it's good to list a unique sand value and IP address to prevent the compatibility issue from occurring. With Windows workstations, we have the other values intact. It's an RSA key type. We can modify the key length and the digester or Shaw value that we'll want to sign with. These are all pretty standard values, and then we'll generate the CSR. We'll export that so we can save it as a file and use it for a subsequent request if needed. In this case, for interaction with Microsoft Certificate Services, we want the actual contents of that CSR. So we'll check it and view it, and we can see the CSR contents on this tab. Select all of those and copy them into our copy buffer. Go back over to Microsoft Directory Certificate Services, excuse me, and go back to the home page and request a certificate. In this case, it will be an advanced certificaterequest because it will not be for a userpaste in the contents of the CSR. And then we'll indicate that we want to use this certificate for web services and submit. And we'll select base 64-encoded data for use with Ise and download that search. It's going to utilise the same name as the CA, but Firefox will prevent the name conflict from being a problem here. And then we'll go back to Ise and get our CSR screen or pending CSR in place. And now we'll want to bind that ID certificate to that CSR. So browse for the file, we see thatwe've got a new Cert, new it wasrelabelled as a one and current date there. And we'll open that up, and we'll indicate that we want this certificate to be used for administration. And we get a pop up there indicating that this will cause an application server restart of all notes that are in the deployment, and we'll see a little bit of downtime as a result. Again, this is going to replace that system-inner node certificate and, of course, our portal, the administrative portal that we're utilising here as well. And then we'll submit that. Okay, we get informed that it will restart and log us out of the system. And we'll pick things up in the next section with a little bit of a walkthrough of certificate trust and obtaining an ID certificate for use with IC, and then we'll pick things up, as I mentioned.

10. Certificate Enrollment Part 2

In this session, we will be completing the certificate enrollment to obtain a trusted ID certificate for use with Ise. And then as we finish, the section will make some changes to how Radius logging behaves. Our ISC application server got restarted from the last section; we got logged out here. We're back at the login screen for IAC. We're still seeing the trust warning at this point, but if we issue the login and start to interact with ISE, we should see that change. And sure enough, now we've got no particular warnings from the ID certificate that he is currently sending us. I should point out that as part of this lab's setup, the trusted CA cert for the lab has been added to the Firefox browser. As a result, any received ID certificates signed by that are now also trusted. Look at the contents of this certificate, see that we've got a secure connection, and if we look at more details, we can view the contents of that ID sort. You can see the subject information corresponds to what I supplied in the certificate signing request, and we can also see the subject alternative names or sayings that were added to that cert signer. And down below here, we should be able to see the validation period as well. Okay. Back on, is it? Let's fine-tune what we want this certificate to be used for. Go into "administration certificates." We see them under our system certificates. We still see in some places the default self-signed server certificate and the one that was just added from our root CA. And of course it's got kind of an oddball name in there, which we can straighten out for use with the certificate. We'll add a friendly name, and we can see the Sands listed here as well. It's already in use for admin. We're seeing evidence of that in the trust that we're obtaining from the Firefox browser. We also want to use this trusted ID certificate for EP authentication, and it lets us know that only a single search can be supplied for each overall within our system deployment. And so this will remove support from the self-signed certificate and place it on this new trusted ID certificate. and we'll also set it up for portal usage. In this case, it's not specific to any portal. We'll add a portal group tag that we can apply when we go to configure a portal. We configure or select this portal group tag, we apply this trusted ID certificate, and then we say that we get a service response that we were successful. We can see our renamed certificate and what it is currently being used for. And almost all functions have been removed from the original self-signed certificate for purposes of the lab. We're going to make some modifications to Radius settings. Step through this process here. Go now to the administration system and settings. You can see a variety of settings, and I will be poking around in this area for future sessions. In this case, we're wanting to select protocols and radius. And in particular, what we're wanting for our lab purposes is to prevent the suppression of failed client login attempts that we want to see and not have those suppressed. And then likewise, we want to not suppress successful authentications. These are left on by default to prevent over-utilization of disc space on the nodes that are running the monitoring or MNT personas. And this little suppression reduces the size of the logging that's needed and just dampens the level of detail. So it might be helpful to uncheck these options, as we're doing for the lab support in an early install or early deployment of ISe, to make sure you're clearly understanding all the potential effects. And then, once things are initially working to your needs, we can check these boxes back on and say that dispatch informed us that we modified those. Change might take a moment to take effect. You see the confirmation message down at the bottom. And I also wanted to point out that if you're not sure what options were checked or unchecked, you can always issue or click this Reset to Defaults button to restore those original Cisco default settings. In this session we finished out the establishment of a trusted ID certificate for use with Ise in particular. That has always had a positive impact on administration browsing. administrative browsing in Ise. And ultimately, this will provide positive impacts for any PC or endpoint device that's receiving an ID certificate. We've got the opportunity to create trust around that by simply trusting that CA when it's imported and trusted at an end point, or perhaps considering distribution as something like a Microsoft domain policy. which is a nice fit for that Microsoft-based certificate authority that we're using.

Cisco ISE Policy Enforcement

1. Using 802.1X for Wired and Wireless Access

IEEE 802 Onex provides port-based authentication. Network devices have the following roles The supplicant is an 802One X compliance software service on endpoints. It communicates with NAD authentifiers to request network access. These NAD authenticators control access to the network based on client authentication status. How do clients actually get authenticated? The authentication server role does client authentication as performed by Cisco Ice. It validates client identity and notifies NaD Authenticators of client authorization status. You may also have back-end servers for Active Directory and Certificate Authority services. Now, the objective here is for endpoints to authenticate to the authentication server via some extensible authentication protocol, or EAP. NAT authenticators act as an intermediary or proxy between the client and the authentication server. They communicate with endpoint supplicants via 802One X to request identity information. The NAT authenticator then relays this information to the authentication server in a Radius message. We should zoom in to get a bit more detail about this communication process. Either a supplicant or authenticator can initiate authentication. In this example, the supplicant initiates by sending an EAP overland or EPault start message. The Authenticator requests client identity with an EAP request or Identity Frame, and the Supplicant responds with an EAP response or Identity Frame. Now, here's where the authenticator begins to serve an intermediary role. It harvests the identity information from this packet, creates a Radius Access request, and sends it to the Cisco Ice Radius server. Some challenge and response frames go back and forth, and if the credentials are correct, the port is authorized. The specific exchange of each frame varies based on the authentication method you choose to deploy. The figure is intended to depict the three phases of the 82 One X authentication process: the beginning, the middle, and the end when the endpoint logs off and the port becomes unauthorized. Now, as a result of successful authentication, Cisco Icecat performs per-user or per-group authorization. For example, it can associate a VLAN with a particular user or group. The Ice authentication server can also associate an access list, or ACL, with a particular user or group, named ACLs for wireless users and downloadable or DACLs for wired users. The NAD dynamically assigns the ACL to the user session, so this gives you very granular access control over your users. Security Group Access, or SGA, gives you a very scalable way to control access. With SGA, ingress switches classified data traffic for a particular role and tags the traffic with security group tags. The Egress network devices evaluate these tags and filter packets by applying Security Group access lists. Let's take a deeper look at VLAN assignment. Every wireless LAN and wired switchport has a default VLAN. However, you can configure the Cisco Ice Authentication Server to override this for certain users or groups. This dynamic VLAN is configured on the Cisco Ice Radius Service and communicated in a radius access accept message. For example, suppose a sales associate connects their laptop to a switch when they authenticate. Cisco Ice recognises that they are members of the Sales Group. Thus, the user is authorised without a VLAN override and is on VLAN 30. However, Cisco IOS recognised some other users as members of the Sales Manager group. Thus, Cisco IOS tells the switch to dynamically override this default VLAN and place this endpoint in VLAN 40. Named ACLs provide differentiated access for wireless users and are configured locally on the WLC, the wireless lane controller. You merely reference this access list in a Cisco Ice authorization policy, ensuring, of course, that the name you specify in Cisco Ice matches the WLC's actual access list name. That's important. Okay, now, when a user requests access, the Ice Radius server authenticates and authorises the user, then informs the controller which ACL it should use. The WLC dynamically applies the specified ACL for this user session, so that's a named access list for wireless users. Downloadable ACLs provide differentiated access for 802 one-X authenticated wired users and are configured on the Cisco Ice Radius server. So when a user requests access, the Radius server authenticates the user and sends the appropriate ACL attributes to the switch. The switch applies these attributes to the port during the user session. The switch removes the per-user ACL configuration when the session ends; if authentication fails or if a link down condition occurs, the switch does not save Radius-specific ACLs in the running configuration. When the port is unauthorized, the switch removes the ACL from the port. OK, did you notice the big difference between switched DACLs and wirelessly named ACLs? Remember, named ACLs are configured locally on the WLC, while switch DACLs are configured on the Cisco Ice Radius Service. Here's a DACL example, which is also an example, by the way, of standard Radius Server's ability to support so-called vendor specific attributes, or VSAs. This downloadable ACL VSA is passed to the switch line by line as a result of the authorization process. This DACL represents one possible way to change the authorization level of a user. Change of Authorization, or COA, is a standards-based method to change endpoint authorization status to dynamically modify active sessions. Now, for this discussion, by the way, I might shorten the words authentication to Auth C and authorization to Off Z. Initially, the device is not authenticated. There is a normal ACL configured locally on the switch and applied to the switch port. So this ACL allows very minimal permissions for only the traffic that is absolutely necessary to get authenticated. Now, after successful authentication, the endpoint posture remains unknown. Authorization may use a downloadable access list that allows Cisco Ice to perform profiling, security posture, and guest services. Once endpoint posture compliance is verified, CiscoIce sends a COA message to the authenticator and supplies extended access privileges. Typically, this is a DACL. Cool. Did you see how we went from unauthorised minimal access to slightly elevated access and then to full access? That's the power of COA.

2. Using MAC Authentication Bypass for Wired and Wireless Access

Static Mac authentication bypass, or MAB, uses a Mac address for both the username and the password. This is the most basic form of authentication used for devices that do not support it. But there are some concerns. Because Mac addresses are easily spoofed, they are a relatively weak form of authentication. Even so, they are still a good first step for device identification. On the plus side, Mapenhances your network visibility. The system can link the device's IP and Mac addresses with a connected switch and port. It's quite useful for security audits, forensics, and troubleshooting. You get identity-based services. All of the 802 One X dynamic authorization techniques also work with map VLAN assignment, ACLs, and SGA. Also, map access layer two allows you to control network access at the edge. Map can be deployed as a fallback mechanism for 802 Onex. When endpoints connect, the NAV tries to use eight, two, one x.If there's no response, it tries MAB next. Of course, Map can also be deployed as a standalone authentication mechanism. And remember the primary use case for Map IT: it can authenticate non-800 and 211-capable devices. Now, this is good stuff, but there are limitations. Remember, network access devices should learn the Mac address of Endpoints and send this to the Radiusserver as both the username and the password. How does the Radius server know whether these Mac addresses are valid? This requires a pre-existing database of acceptable Mac addresses, which you have to create and maintain. could be a little bit of work. And when used as an 82 dotOne X fallback mechanism, there's delay. MAB waits for Ice to timeout before validating the Mac address. These delays can negatively affect endpoint functionality, although mitigation techniques are available. Now remember, MAB only authenticates devices, not users. So different users logged into the same device will have the same network access. And finally, unlike the 82 One X, Map is a fairly weak authentication method and can be defeated by spoofing a valid device's Mac address. Okay, so we understand the benefits and concerns. Let's take a look at how MAB operates. MAB enables port-based access control based on the learned endpoint MAC address. It provides a method to handle 800 one-off exceptions. Certain Mac addresses are allowed to skip the regular 82 One X authentication process. Now, initially, Endpoint's identity is unknown. When the switch receives that first frame from the endpoint, it learns the source MAC address. Now, it doesn't forward this frame nor any subsequent frames because the port is not yet authorized. However, it forwards this MAC address to Cisco as a Radius access request message. Assuming that this is a valid Mac address, Cisco sends an access accept message, and the port is authorized. The switch uses source Mac address filtering to help ensure that only the MAB authenticated endpoint is allowed to send traffic on this port. Okay, let's look at a scenario where MAB acts as a fallback mechanism to 802 One X. In the initiation phase, the switch detects a secure link and initiates authentication by sending an EAP request identity message. If the switch does not receive a response, it retransmits the request. Eventually, Adobe One X times out, and the switch proceeds on the map. In the Mac address learning phase, the switch allows the port to accept a single frame and thus learns the endpoint Mac address. This and all prior frames are discarded. The switch sends a radius access request packet, which includes the endpoint Mac address as three separate attribute value pairs, or AVPs. It is used as the username, the password, and the calling station ID. In the authorization phase, the Radiusserver validates the Mac address. If valid, it sends an access accept message. This message informs the switch to allow endpoint port access. The message might also include a dynamic VLAN or DACL. If the Mac address is invalid and access rejects messages sent, all endpoint frames continue to be dropped. However, if alternative authentication methods are configured, the switch may attempt 82 One X or Web authentication or deploy the guest VLAN in the account phase. If the switch successfully applies the authorization policy, it can send a Radius accounting request message to the Radius server with details about the authorised session.

So when looking for preparing, you need Cisco CCNP Security certification practice test questions and answers, study guide and complete training course to study. Open in Avanset VCE Player & study in real exam environment. However, Cisco CCNP Security exam practice test questions in VCE format are updated and checked by experts so that you can download Cisco CCNP Security certification exam practice test questions and answers files in VCE format.