You have to work through this with TAC. I recommend running through the steps of the URT and then submitting the failure log file it spits out. https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/upgrade_guide/b_ise_upgrade_guide_24/b_ise_upgrade_guide_24_chapter_01.html#urt ... View more

There is a very short timeout in earlier ISE versions. The reccomend approach to avoid this is to create a repo that points at the root of disk. Copy the upgrade file manually via ftp to disk: on each node, then during the upgrade use the disk repo. Each node will "download" the upgrade file still, but it will grab it locally. I would rather jump upgrade like youre trying vs going to 2.1 first. It's a lot more work adding additional upgrades. I woule rather build two new 2.4 nodes and restore the 2.0 backup before doing that. ... View more

There are countless reasons for this alarm to be triggered. In your case, you could debug radius or do a packet capture on the switch to see what you endpoints were doing prior to the change. Unless it's thousands per day from the same device, then most just ignore it. ... View more

There are some cisco live sessions on trustsec and I would reccomend giving the cisco live on demand library a visit.   In short though, TrustSec is a method of segmenting traffic via the use of a scalable group tags, SGTs, and SGACL's.    While ISE is not a requirement to implement TrustSec, it's much easier to use a central policy server for your tag provisioning and SGACL/policy. When you authorize endpoints via ISE, you assign a SGT with the authorization result. From that point on, the ip and traffic for that endpoint would be classified with that tag. How you use that tag can vary greatly depending on the design. You use ISE's TrustSec policy matrix to build the SGT to SGT relationships forming the SGACL policy that switches will download/be provisioned with.   There are many ways to implement TrustSec, but the ideal end state is to have all traffic tagged with SGT's and to carry the Tag inline throughout the network. Depending on the security goals, you might want access layer peer to peer blocking on the same switch (east to west), or just central enforcement on a single core switch into a data center (north and south). It's a huge topic within a TrustSec design and there are many intricacies. Without a doubt though, TrustSec's end state utilizing end to end tagging provides unparalleled traffic segmentation. ... View more

I'm assuming you found the ACS to ISE migration tool? Since you self referenced I'll just make a quick note for when people search google and end up here. Each version of ISE has a specific ACS to ISE migration tool to aid in the move. It's not perfect but it saves considerable time in large deployment. When you use the tool you have to go through all of the policy sets and clean up the logic as the tool duplicates a lot of conditions. You can find the tool in each ISE version download section on cisco.com software search, ex. it's nested within ISE 2.4, another is nested within ISE 2.6. ... View more

Can you provide us with the ISE authentication details log. ISE often gives a pretty direct reason for an authentication failure, or we can at least infer quite a bit from it. ... View more

I saw a "bug" in the bug tracker that mentioned logs shouldn't be included in the config backup. If you get bored you can search for it. I think it was filed under an enhancement....of course! ... View more

The only way I have seen this was back in the ACS days with shadow accounts on Juniper. You configure local accounts mapped to the permissions you want, and then from ACS/ISE you send back the user. You leverage a custom attribute like local-user-name to accomplish this. Pretty sure that's what you are trying to avoid. On juniper you would create a RO and super user accounts, set up for the roles you want. ISE authentication still takes place as it would, creating authorization rules based on the AD accounts. Then with the result you send back RO account with "local-user-name" if they match RO only access, and super if they match super. Worked good. Juniper has their short list of attributes documented. Have you considered the allow-configuration and deny-configuration, would it accomplish what you need? https://www.juniper.net/documentation/en_US/src4.7/topics/reference/general/tacas-radius-authentication-attributes.html ... View more

This is not something that anyone should be doing on an ISE deployment, and it won't enable a user to access root or the linux shell. ISE leverages something called ADE-OS which sits on top of RHEL. As indicated by nspasov, you access the underlying Linux CLI via TAC and the root key/root patch. This is not something Cisco provides for end user use, it is only used by TAC during troubleshooting to fix advanced issues. So even if you edit the root password, you need the root key that expires frequently, and the root patch that will work on your version.   It's also a 5 year old thread, no need to bump this.   ... View more

Since if works fine on your laptop using filezilla (this is my preferred server too ), it would lead me to believe it's a Solarwinds problem. A quick search of the solarwinds community has a bunch of threads where people ran in to similar issues, only part of the file gets copied. ... View more

Your server upgrade order looks good, no issue there. As for your other questions. The ISE upgrade package has to be downloaded to every node, if using the GUI to upgrade the deployment this is done during the pre upgrade tasks and often times out if there is a slow wan link. For most upgrades we create a repository for disk:/ and manually copy the upgrade bundle to each servers disk:/ before starting. During the upgrade, the secondary PAN that upgrades from 2.2 to 2.4 first, will then become the primary admin node in the 2.4 deployment. While upgrading you have two separate ISE deployments, one running 2.2 and a new one running 2.4, there is no communication between these two. When the secondary MNT and PSN upgrade, they will register with the 2.4 PAN. 2.2 to 2.4 includes VM license changes. You will have to email Cisco your Cisco sales order number where you originally purchased the RTU ISE vm's. The BU will issue new medium VM licenses for you to install on the 2.4 deployment. You can do this before or after the upgrade with no impact other than a nag message on the dashboard. Read about it here. https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-24/213171-ise-2-4-upgrade-alarms-fewer-vm-license.html "If you are planning to upgrade to Release 2.4, contact ise-vm-license@cisco.com with sales order numbers that include VM purchase to procure one medium VM license for each VM previously purchased. You should also include your CCOID along with the sales order number." One additional side note, I tend to prefer upgrading via the CLI because you have control over the process. When you upgrade from the GUI, I find that nodes will start too soon after the previous, and you have no way to pause and test. If you do this manually you will be able to upgrade the PAN/MNT/first PSN, test, then continue or roll back. Also, make sure you have run the URT bundle to rule out any major issues upgrading. ... View more

No, this 5 day timeout is hard coded in ISE. The NAD will send an accounting stop, assuming it is configured to send accounting updates, when the authentication session is removed. ex. The port status goes down/down when an endpoint disconnects. There are times where the session may remain active, an example of this could be when an endpoint was connected to a phone or transparent switch. The session remains active in sh auth session, even after the endpoint is unplugged. In this cases you can leverage timers to get a more timely resolution. ... View more

When you reload a PSN, no COA is sent to the switch. The node goes down silently from the NAD and endpoint perspective. The completed authentication sessions remain as they did while the node was up. New sessions will be sent to the remaining PSN's based on the radius server configuration on the switch (or load balancer). The second piece, if you change the radius server order on your switch it will not reset the authentication sessions. Any authenticated sessions remain untouched, new sessions and accounting updates will leverage the new primary server when the switch goes to send them. Alternatively, if you leave your radius server config untouched, take down the primary node for that switch, the NAD will have to detect that the PSN is down, either via automated tester or radius timeouts. ... View more

First suggestion is that you should engage TAC to help you out here. Has your ACS appliance core dumped/reload on it's own recently? Not sure if ACS supports this, but issue "dir disk:/localdisk" ... View more

@mhabrcet  2.4 is not supported on the SNS 36xx platforms.  The common messaging right now it to provide the feedback via http://cs.co/ise-feedback . Maybe if enough interest is there then 2.4 will be certified on the 3600's, no one has come out yet and point blank said that it won't work, just that it's not supported. Here's hoping that there is a strong enough business case to assign resources to look at it for us.  ... View more