Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Missing "Edit" Buttons with Integrated Windows Authentication

We had been having long standing issues with our NPM 8.5.1 in that some admin users were never displayed any "Edit" button on any resource. Those same admin users never had any updated/current "Last logged in", and always said, "Never". We had hoped this would be resolved in 9.x but in our NPM 9.1 SP5, we are beginning to see the same problems. We are using the Windows integrated login and have our IIS security settings set as follows:

* Disable anonymous access
* Integrated Windows Authentication
* Basic Authentication

With these set, we sometimes see "Edit" buttons, sometimes we don't. If we disable integrated authentication and enable anonymous, after we have once successfully authenticated WITH Windows accounts, the browser automatically logs us in as if authentication integration is still enabled, and NOW we have "Edit" buttons. This isn't consistent, however.

Right now, we can't get an "Edit" button to show up no matter what we do with Windows authentication. The only way we can obtain "Edit" buttons is to log in with a local admin account that isn't structured in our <DOMAIN>\<USERID> format. Anyone else ever have issues along these lines? We do not want to depart from Windows integrated access to our NPM.

Find more posts tagged with

windows_integrated_login

last_logged_in

edit

Accepted answers

All comments

vhcato

That's odd. As long as the correct username is represented in the upper right-hand corner of the Orion web page, and that domain user's account within Orion has the "Allow Account to Customize Views" parameter set to "Yes", then they should always see the "Edit" buttons. Do you also have a <DOMAIN>\Everyone account configured in Orion that is perhaps being used instead of the specific user's account? I know that's a long shot, but I thought I'd throw it out there.

vhcato

Just curious...

Why would you need the "Basic Authentication" method enabled?

chris.schear

All of our accounts are created in Orion as DOMAIN\username, and we DO have an "Everyone", but that doesn't appear to be the issue. The correct logged in user is displayed in the upper right as it should, we just lack EDIT buttons. The Admin functions still work. We can perform any administrative option we want (assuming, the accounts are supposed to have admin rights), but the EDIT buttons from the resources are missing. The EDIT buttons ARE NOT missing from the NCM-integrated modules, just the NPM propper.

chris.schear

If the box is checked, it's probably because someone at Solarwinds advised us to set it up that way, or the original 7.x NPM and instructions how to integrate called for it. I can't really say why it's needed.

chris.schear

This is what is further puzzling. I have my IIS Directory Security now set (experimenting) as follows:

------------

- Integrated Windows Authentication

- Digest authentication for Windows domain servers

Realm: corp.ruan.com

------------

Essentially, I removed basic authentication and enabled Digest, so I could specify the Realm. Otherwise, it's grayed out. When I do this and log in as an Admin, SOME EDIT buttons are present. I have found the following:

1. NONE of the Edit buttons on the Summary page exist.

2. SOME of the edit buttons on a Node Details view exist, SOME do not.

It looks like EDIT buttons on CHARTS and GRAPHS are being displayed, but not on resources like "Custom HTML", "Selected Node Properties", "Event Summary" or "Last XX Events". All universal poller resources have edit buttons, as well. So, the issue of not having an EDIT button doesn't seem to be consistent across views and/or resources. It exists in some places, but not all places. Clearly, it looks like the underlying code to display the EDIT button differs, and I'm going to start digging through resource files to see what is different.

chris.schear

Using Firefox...

The first visit to NPM creates a browser-based dialog box prompt. Once logged in, only some of the EDIT buttons are displayed (as described previously). If we use the NPM "Logout" and provide our DOMAIN\username & password in the NPM login box, once we log in...EDIT buttons are magically back.

AlbanyNYMike

We have WPTA working perfect, although we did hit a few bumps along the road.
The roadblock for us was the way we were creating the user accounts.

Create a new account in the DOMAIN\user format.

Create a PW!!!! That is what was stopping us. Its a dummy PW and will never have to be used.

Remove the login page. To do this, we would remove the "login" portion of the http address.

Old Orion quick link looked like this http://SERVER/Orion/Login.aspx

New one http://Server

Save new link as a FAV.

Yoru IIS settings appear fine. And double / triple check that the admin settings are applied to your admin users.

vhcato

Good point about making sure your URL is not forcing you to hit the login page. Without explicitly stating to hit the login page in the URL, you are not challenged for authentication if you are logged in with domain creds that match a locally configured Orion account. For users who do not have a local account on the Orion server, they will still be presented with the login page even though it's not specified in the URL.

We modified our Login.aspx to include links (with embedded creds) that can be used to access specific views of interest to them without the need to include their accounts in Orion. With this configuration, those who have their domain accounts configured in Orion will have seamless WPTA, and those who don't are presented with a login page with links to various views of interest.

BTW, if using the default login page, one can still enter the DOMAIN\UserName creds that are defined in Orion, but it has to be the same password that was created in Orion and not the true AD password (unless they happen to match).

I don't think this is going to help with the "Edit" button issue though.

chris.schear

After much troubleshooting, trial and error, for whatever the root cause, we have found that bad cookies are the culprit. Across multiple machines, if we clear cookies and access the front-end, the issue(s) are resolved. Solarwinds believes at some point, possibly, the NPM application threw out a corrupt cookie and it skewed the IF/THEN functions within the resources to display the edit button. Different resources must be coded (slightly) differently in this regard, because only SOME resources were lacking Edit buttons in certain trials.

Bottom line, if you are having this problem...clear cookies, rinse and repeat.