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

Account Limitations

So, what's the deal with account limitations? Is it not possible at all to have a view that includes a limitation based on more than one option? Many of our customers have both node-based and interface-based services and could benefit from having only one login.

Is there any way this type of view could be supported?

-evt

Find more posts tagged with

Accepted answers

All comments

DonYonce

evt,
I'm not sure I understand your question....

If you want to limit an Account to a group of Nodes AND a group of Interfaces, add more than one limitation to the Account.

For example, when editing the Account click on "Add Limitation" and add a Group of Nodes. Then click on "Add Limitation" again and select "Group of Interfaces". You will now get a list of Interfaces to select from the previous Group of Nodes.

In the default setup, you can add up to 3 limitations per Account. You can do a lot with three seperate sets of limitations. Limit by Building, by Device Type, and Interface Type. (for example, limit an Account to only view Ethernet segments on Servers within Building A)

You can also extend Account limitation from supporting 3 limitations per Account, to supporting up to 6 per Account. Within the Accounts table in the Orion SQL Database, there are thre fields named LimitationID1, LimitationID2, and LimitationID3. Using SQL Enterprise Manager add new fields called LimitationID4, LimitationID5, and LimitationID6 to extend the Account limitations to 6 per Acount.

Also, within version 7.7 you can now limit Summary Views also. In previous versions, limitations could only be applied to Accounts. Within version 7.7 and later, you can create multiple Summary Views each with their own limitation assigned. For example, you could create a view called "Top 10 Servers" and limit it to only display statistics from a group of servers. Another view can be created called "Internet Traffic" and limit it to upstream Internet links. When "Network Wide" traffic charts are added to this view, it will be limited to the group of Internet links only.

bleearg13

quote:Originally posted by Don Yonce

If you want to limit an Account to a group of Nodes AND a group of Interfaces, add more than one limitation to the Account.

uhh, yeah...I guess it's RTFM for me

I had no idea you could add more than one limitation to an account.

quote:
For example, when editing the Account click on "Add Limitation" and add a Group of Nodes. Then click on "Add Limitation" again and select "Group of Interfaces". You will now get a list of Interfaces to select from the previous Group of Nodes.

In the default setup, you can add up to 3 limitations per Account. You can do a lot with three seperate sets of limitations. Limit by Building, by Device Type, and Interface Type. (for example, limit an Account to only view Ethernet segments on Servers within Building A)

I just tried this and it appears to be confused because I have both limitations set to 'CustomerID' in Nodes and Interfaces. I get:

SQL Open Error : Ambiguous column name 'CustomerID'

when attempting to add this limitation.

quote:
You can also extend Account limitation from supporting 3 limitations per Account, to supporting up to 6 per Account. Within the Accounts table in the Orion SQL Database, there are thre fields named LimitationID1, LimitationID2, and LimitationID3. Using SQL Enterprise Manager add new fields called LimitationID4, LimitationID5, and LimitationID6 to extend the Account limitations to 6 per Acount.

Ok, maybe I can fix my above problem by setting the limitations manually in the DB. I'll try this out and post if/when it works out.

quote:
Also, within version 7.7 you can now limit Summary Views also. In previous versions, limitations could only be applied to Accounts.

I knew this, but from what I can tell, the limitation has to be selected right then and there when creating the View. This means that I have to create a separate view for every login to Orion, which can get very messy and doesn't scale. Unless I'm missing something (which is very possible), this won't work in my situation.

Thanks for the tips, Don. I'll try them out and let you know how it goes.

-eric

bleearg13

Ok, so after the Account Limitations Builder wouldn't let me add both 'Nodes.CustomerID' and 'Interfaces.CustomerID', I added it manually, which appeared to work and create a new row in the DB.

Unfortunately, I still get the error about an ambiguous column name. It looks like the ConfigurationLimitation.asp page is performing a SQL query on just 'CustomerID'. If I can add properties from three or four different tables, why won't the page let me query for the right table?

I also tried different combinations of adding account views, but nothing got what I needed. I cannot seem to give access to a Group of Interfaces without adding the parent node. When I did this, the Node was available on my summary page and the user had complete access to view that node, IOS image version, syslogs, and all.

My exact scenario is that we have customers that purchase servers from us - they need to have full access to view the statuses of those nodes. They also purchase access-based services such as DS3 or T1, which require them to have full access to just a specific interface. I do not want them seeing the properties of the parent node, nor do I want them to see the other interfaces in that router or switch.

thorpe

The only problem is I see is they have to meet all the filters or they dont see any. For example if I want someone to see all nodes with IP 10.30.xx.xx I setup a rule for that and so far so good then I want them to see node 10.66.23.22 and I then want them to see all nodes that start with THY in the name so I set that up. well unless the node has all 3 as part of that node then you done see anything.

bleearg13

So I take it that there's no way to do what I want to do? It seems like all that is required is a quick rewrite of the ConfigurationLimitation.asp page to allow a query of both the Interfaces and Nodes view, unless I'm missing something. The Limitations should be doing a logical OR on the query (Nodes.CustomerID = cust-a OR Interfaces.CustomerID = cust-a). I would do this myself, but I'm not an ASP programmer.

Anyone from Solarwinds want to help/chime in/tell me to shut the hell up and deal with what I've got?

Just to be clear, I understand that one can limit based upon a group of nodes and a group of interfaces of those nodes. The problem is, this does not scale. If a customer signs up for service at another POP or leases another server, a manual selection of the new node must occur for the account. The nice thing about limiting by custom properties is that this is almost entirely dynamic. Any new node that's added with the same customer ID is automatically added to their summary views.

thanks,
eric

AndrewT

If you need to build limitations for multiple items you can use OR command. Example:

Siemens* OR Verilink*

This allows user to see all devices with the name that start with Siemens or Verilink

DonYonce

Eric,
I now understand what you are needing. You want an Account to view all nodes with Customer #ABC AND all Interfaces with Customer #ABC.

I setup a test server to try and discover a solution for this issue. But I struck out.
The problem is ... Account limitations will only show objects that match ALL limitations.
Let's assume we add two limitations to an Account: one for Nodes.CustomerID ='#ABC' and another for Interface.ICustomerID = '#ABC'.

So.. if an interface has CustomerID #ABC, it will not show up unless the Node ALSO has CustomerID #ABC.
This breaks your original requirement of only showing the Interface belonging to the customer, not the Node. It also makes it hard to manage.

The best thing I can reccommend at this time is give the Customer two logins, one for Servers and one for Interfaces.
Limit the Servers login to Node.CustomerID = '#ABC' and limit the Interfaces login to Interfaces.ICustomerID='#ABC'

I'll keep investigating this also. I may come up with something.