BIGIP 9.0 - Root vs. Other Accounts

iControl uses the same authentication mechanisms as the web gui. I believe that by default the "root" user is not defined in the gui's authentication database. In the gui, if you look under System and click on Users you more than likely won't see "root" listed. I believe root is meant to be a console only login.

 

 

With that being said, you can create new users in the gui for both web gui access as well as iControl.

 

 

-Joe

Thanks for the help Joe

 

 

-tom

F5,

 

 

Continuing along these lines I have 2 more questions.

 

 

1.) So am I right in assuming that iControl calls are split in terms of access? Thus is there logic that seperates read calls vs. write calls?

 

 

Essentially what I am wondering is if I have say a Operator level account in the WEBUI, does that Operator account have operator level access to iControl as well as the WEBGUI? And further along those lines, does a WEBGUI admin account have full access to iControl, does a guest account have just read access, etc.?

 

 

2.) I know that the /config/httpd/conf/httpd.conf file allows me to do IP ACLs on the WEBGUI under the following heading:

 

 

================================================================

 

*** Section Removed

 

================================================================

 

 

Does this section also apply to locking down iControl access or is that a seperate section in this file, or can it not be done?

 

 

Thanks,

 

 

- Tom

Hi Tom,

 

 

1- Yes, iControl calls are split in terms of access. Any BIGIP users will belong to one of 3 classes: Administrators, Operators, or Guests. The user and his/her corresponding access level is created from the Web GUI. Although there might be some minor variances in how access is controlled between the GUI and iControl, but in general, it's very similar. If an iControl user is an Administrator, he/she can make any method call. If the user is an Operator, he/she can do get/query/find/is methods, as well as enabling/disabling virtual addresses and virtual servers, and also up/down nodes/pool members. If the user is a Guest, he/she can only have read access, i.e. get/query/find/is type of iControl methods.

 

 

2- There's a separate section that controls authentication/access for iControl within the same httpd.conf file.

 

 

Hope this helps.

 

Loc

 

Thanks, this is great.

 

 

Can you please point me to the correct part of the httpd.conf file that I should use to accomplish Allowing/Blocking IPs?

 

 

Thanks,

 

 

-tom

Hi Tom,

 

 

In /config/httpd/conf/httpd.conf, the section pertaining to iControl is:

 

 

 

.....

 

 

 

However, care must be taken when editing this section, as mis-configuration can potentially negatively affect certain aspects of the GUI as well as iControl.

 

 

Regards,

 

Loc

Thanks again.

 

 

2 More Questions here:

 

 

1.) Ok, so is default iControl behavior to accept conections from anywhere? Based on the file defaults in the section you descibe it look like it denies from everyone but 127 (the loopback) and yet I have developers who seem to be able to use it fine over the Overdog port, and I dont recall ever modifying this file for them before.

 

 

 

2.) If I understand correctly then for me to allow access to say someone over IP from 1.1.1.1 I would just modify line 1076 so it would look like this:

 

===================================================================

 

*** Section Removed

 

===================================================================

 

 

Thanks,

 

 

-tom

Hi Tom,

 

 

The default behavior is to deny everyone unless they're authenticated, except for local connections. So you don't have to explicitly add any IP address to allow someone to access, since if they're not explicitly specified, they will just be authenticated, and if authenticated successfully, they'll be allowed access. There's a little difference in how the configuration sections for iControl and TMUI might look, but that's just a special case for local connections.

 

 

With that being said, you don't even have to add him to the /tmui section since by default that directory will allow access to everyone who's authenticated.

 

 

So in short, the user you mentioned was not smoking crack. :-)

 

Loc

Yeah, that makes sense since I was able to recreate him having access by rolling some sample code last night and watching it work. Ok so if he's authenticated he's all good that makes sense.

 

 

So on the flipside then, if I denied him IP in the /TMUI section but he had a valid account to auth, then I assume that similarly to how he would not be able to pull up the WEBGUI despite having valid creds, he would also not be able to access iControl?

 

 

thanks

 

 

-t

The TMUI and iControl are configured in different areas so changes to the TMUI section to limit access is independent of the iControl section.

 

 

But, if you choose to modify the sections of the configuration file by hand, I'd suggest you do so with the support of F5 Product Support as it could have adverse effects and cause the product to not function properly if configured incorrectly.

 

 

-Joe