I have searched the posts and tried various things but cannot come up with a solution.
I cannot get RME to acknowledge new credentials set in tacacs+. Campus sees them when I attempt Management Station to Device but all modules in RME do not. Cannot run Archive, Software, Netshow.
Have verified credentials in export. tacacs not logging errors against username and I am remote so don't have sniffer.
Any help would be so great about right now.
I am getting very sporadic responses. I actually put all of my credentials back to the old tacacs login/password, thinking there was something wrong with the new tacacs credentials I created (even though they work when I apply them manually) I exported the credentials from DCR to ensure they were correct, stop/started the Daemon and then tried a random number of devices. Some succeeded some failed. I cannot find rhyme or reason in the configs (new aaa model vs old), or device type (switch or router). When I use the credentials manually they work in every device, my personal login (tacacs+, AD), old CW admin login (tacacs+, AD), new CW admin login (tacacs+ only). I rerun the failed and get the same results.
I discovered this because I built out 48 new blade server switches (3020) (don't make fun of my decrepit old network parts)and I cannot get to them via telnet no matter what the CW credentials are, but can log into them everytime with all manual credentials. Another interesting thing, tacacs logging doesn't see CW hitting the devices, whether it succeeds or fails.
What is totally great, is I can TELNET okay to ALL of them from Campus (Management Station to Device) and have pulled configs for most(have the transport set for telnet).
I am LMS 3.2 RME 4.3 and ACS18.104.22.168
Choose a couple of the problem devices (different device models), Delete them from the DCR. Re-add them.
Let me know if they work properlly after that.
I have narrowed it down to the ACS that the devices are pointing to. I have deployed ACS 5.3 and am moving devices to point to it. The credentials work when I login manually but not through RME to ACS. This leads me to believe that the aaa and ACS are not configured incorrectly. argh.
No, don't be frustrated, this is good news!
I say that because ACS/LMS integration issues are 99% of the time just a simple misconfiguration. And I have an excellent integration document for integrating your LMS 3.2 to ACS. Please check this over and match it to what you are seeing:
This is a very good step-by-step guide that should help you configure ACS with LMS correctly. Look carefully at the notes as much of the problems are usually related to a mis-configuration. Once you have this setup, you can easily modify the permissions for the users and groups. Hope this helps. Please let me know if you have any questions or if this is what you were looking for. ON CISCOWORKS =============== 1. Go to Common Services > Server > Security > Multi-Server Trust Management > System Identity Setup and configure a System Identity User. *Note: This System Identity User is NOT the same as the ACS admin user, it has to be different. *Note: If you get a popup error that says null, let me know because that means that you are missing the comUser.dat file and I would need to send you extra steps) 2. Ensure that the System Identity User you just created is a local user with all the roles under Server > Security > Single-Server Management > Local User Setup. ON ACS ======= 3. Define a group for CW Admin Users in ACS. 3.1. Go to GROUP SETUP. 3.2. Rename an available group to something suitable such as CWAdmins. 3.3. Edit Settings. 3.4. Set sessions available to user to 'unlimited'. 4. Add the CW system identity user (and other Admin users in CW) to ACS. 4.1. Go to USER SETUP. 4.2. Create Users for Ciscoworks including the System Identity User in ACS. 4.3. Set a password. 4.4. Assign all these Admin users to the Group created in Step 3. 5. Add a network device group with Ciscoworks as a Client. 5.1. Go to NETWORK CONFIGURATION. 5.2. Enter a Name. 5.3. Enter IP address or range with wildcard masks. 5.4. Configure a Key. 5.5. Authenticate using: TACACS+ (Cisco IOS). 5.6. Click on Submit+Restart. Note: (If NDG options are not visible, you can enable Network Device Groups in ACS under INTERFACE CONFIGURATION > ADVANCED) ON CISCOWORKS =============== 6. Change CW AAA Mode to ACS TYPE (and register CW applications with ACS). 6.1. Go to Common Services > Server > Security > AAA Mode Setup. 6.2. Select ACS type. 6.3. Fill in IP address/Hostname of ACS server 6.4. Fill in the ACS admin login information and the shared key Note: "ACS admin login" must be a user with full admin rights to ACS (i.e. one configured under Administration Control in ACS with ALL options checked) and should not be the same as the System Identity User. 6.5. Put a check mark on "Register all installed applications with ACS". 6.3. Click on apply. 6.4. Restart the daemons with these commands from a command prompt window on the LMS server: >net stop crmdmgtd >net start crmdmgtd *WARNING: Make sure that AFTER the first successful registration to any specific ACS server, you always keep this box UNCHECKED if switching between ACS and non-ACS modes on LMS server. Failure to do so will erase all custom roles (SUPERUSER) and you will need to do steps 7-8 on ACS again. ON ACS ======= 7. Add a "SUPERUSER" role for each module of Ciscoworks in ACS. 7.1. Go to SHARED PROFILE COMPONENTS. 7.2. Select a CW module (such as Common Services). 7.3. click on ADD. 7.4. Name it CWSuperUser or something similar. 7.5. Select everything under the available functionality for that module. 7.6. Repeat above procedure for Ciscoview, RME, Campus, DFM and any other Ciscoworks modules such as IPM, etc. 8. Assign the "SUPERUSER" role to the Admins Group (created in Step 3). 8.1. Go to GROUP SETUP. 8.2. Click on Edit Settings. 8.3. Select cwhp, rme, campus, dfm and any other CW components a select the "SUPERUSER" role (created in step 7). 8.4. Click on Submit+Restart. *Note: Once ACS mode is enabled on Ciscoworks, ALL devices MUST be added to the same ACS server as clients for them to be manageable in Ciscoworks. While the devices must be known (i.e. configured as clients) in the same ACS server, they do not have to use that ACS for their own AAA configuration, nor do those devices need to be configured for AAA themselves. Here is also a link showing screenshots, it is for 4.1 but applies the same for 4.2: http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps6504/ps6528/ps2425/prod_white_pape
I am a little confused by this. I am not using ACS as my Current Login Method. I am using the local database(Non-ACS). I did work through the directions up to step 6.3 and it failed
Tacacs+Connectivity: Reachable all other Not Applicable
Note: Verification failed for all ACS server(s).Please check your settings
I attempted this multiple times and got the same results.
Also 5.3 is really different. I am totally aggravated by how different it is from the last version.i cannot find Shared Profile Components anymore.
I found this in another post:
We are also using default tacacs+ prompts with ACS 5.1. After updating the tacacsprompts.ini the issue was resolved. The error message with missing username appears whenever LMS (or other monitoring system) uses SNMP to poll the device for config. At least that's what I see in our logs. Whenever LMS can't login and uses SNMP, ACS just spams the log with missing username errors.
Yes now it works fine.
We changed tacacsprompts.ini file to :
Is this something i should do?? how does this affect the devices that I have not changed their tacacs server to point to the 5.3?
oh the agony. lol
You've successfully confused me.
Based on what you've said, you have some devices using ACS 5.3...and the others..???
Ah-ha my true calling! The confuser of brillance =-)
I have tacacs+ in my environment, authenticating/authorizing, really just as a passthrough for AD. I login to a device using my AD credentials. I had 4.x something (I haven't seen it because I am new and haven't acquired login for it)and now also have 5.3. The devices are in a mix of pointing to the 4.x and the 5.3.
My CW was using an AD account to telnet/ssh to devices to do it's stuff. I decided I didn't want it to use AD credentials and they were very old, so i created an internal account on ACS 5.3. I tested it by telnetting to a device and waala it worked. I then went to DCR and created a new credential set with the internal account. The devices that were pointing to the new ACS 5.3 (because i didn't put it on the old 4.x)should have seen CW with the the login, gone to the new ACS and waala, CW is now authenticated/authorized to do its stuff. That didn't work. I exported the DCR to check for accuracy, I added-readded, changed the tacacsprompts.ini file, nothing worked. So I panicked and put it all back like it was, to the old tacacs+ AD account, removed the tacacsprompts.ini file entry. Now nothing works that points to the 5.3. And I am pushing IOS by hand ugh.
I think this is sufficiently complex enough at this point that we're going to need some debug enabled logging and possibly packet captures. That said, I believe it would be beneficial for you to open a TAC case, and then we can get our escalation and Development Teams involved.
Is opening a TAC case a possibility for you?
Yes! I will do this. I am going to Prime in the beginning of the year but don't think I can wait that long to get this fixed
Thank you so much for your input. I am sure we will meet again... (run, don't walk)