Access Mode in Sites

| Print out this category

Access Mode in Sites
With SSO-H, access to Active Directory within site can be prioritized or restricted, so there is a setting called 'Access Mode in Sites'. Sites programmed in Active Directory comprise multiple subnets. In this mode, SSO-H uses site information to access the same site as the device, or the subnet Active Directory.
The SSO-H default setting is with the site internal access mode OFF.
Access Active Directory within same site only.
If there is no Active Directory within the same site, or if connection fails, there will be an authentication error.
Access another site if Active Directory within the same site cannot be located.
If there is no Active Directory within the same site, or if connection fails, an Active Directory external to the site will be accessed.
If all attempts to access Active Directory fail, there will be an authentication error.
The operating specifications of the site internal access mode are as described below.
When first logging in to the login service after booting iR, the domain controller (DC) is obtained from the site list.
However, upon the first login, even if the site functionality is active, connection to DC is random. (This is because, if connection to DC should fail, the site to which the device belongs cannot be ascertained.)
If the device IP address or the domain name are changed, the site settings are acquired once more.
In this mode, at the first login (first authentication of domain to which the device belongs) LDAP-Bind is performed directly to DC and site information acquired by LDAP from DC.
From the acquired site list, the site to which the device subnet belongs is extracted and this becomes the site to which device belongs. Active Directory address is acquired (retrieved from DNS)
Note:
The Active Directory subnet is assumed to be the same subnet as the device sub-net.
In the Active Directory addresses, the Active Directories of the same site are listed.
Active Directories of the same subnet as the device are listed first.
If there is no Active Directory with the same subnet as the device, Active Directories belonging to different subnets than the device are listed.
The Active Directories within the same site are accessed in order. Note, however, that where there are multiple Active Directories within the same site, access to those Active Directories will be in the order in which the address list was obtained.
Note:
If there is no Active Directory within the same site, if access outside of the site is programmed, Active Directories outside of the site will be accessed in the order in which the address list was obtained.
Site list acquisition
After booting up, upon the first login by LLS or ILS/ RLS, the site list is obtained from the Active Directory. In order to obtain the site list from the Active Directory, Active Directory needs to be accessed in LDAP, so SASL-Kerberos-Bind is used by the login user account. If authentication by Active Directory should fail, an authentication error will be generated and the site list will be acquired again from Active Directory upon the next login.
In SSO-H, the Active Directory to be accessed when acquiring the site list cannot be specified. In other words, if there is no site list, which site's Active Directory is accessed depends upon the order of the Active Directory addresses returned by DNS. Therefore, when acquiring the site list, LDAP may access the Active Di rectory of a different site. Therefore, in such cases, it is sometimes necessary to access across sites or subnets, which means that LDAP protocol needs to have continuity across sites (subnets) (normally, LDAP is port No. 389). Further, if connection with Active Directory fails when acquiring site information, another Active Directory will be accessed.
Site information, once it has been acquired, is cached within the device. The life settings of the cache can be set so that site information in the cache is updated upon the first login after the device boots up, or so that the cache is not updated once acquired.
Settings for access mode in sites
Switching between site internal access mode/ non site internal access mode, as well as detailed mode settings, are done via DMS or iWEMC.
Site internal access mode settings window (DMS)
The figure below shows a sample of processing Access Mode in Sites.
Sample of Processing Access Mode in Sites
1) SSO-Tokyo acquires site lists from Active Directories.
Note, however, that the Active Directories accessed in order to acquire site lists are in the order in which they were returned by DNS, so there is no guarantee that the same Active Directory will be accessed as in the initial settings (upon device settings or changes to NW settings, etc.).
[ Site subnet list ]
Site: Tokyo: = 172.24.12.0/24, 172.24.35.0/24
Site: Osaka: = 192.168.1.0/24
Site: Hakata: = 211.111.1.0/24
As a result, since SSO-Tokyo is 172.24.12.80, the subnet is 172.24.12.0/24, and is judged as belonging to site Tokyo.
2) The DNS server obtains its Active Directory list from the primary or secondary DNS, as set in the device.
[ Active Directory ]
172.24.12.2, 172.24.35.2, 192.168.1.2, 211.111.1.30
3) Of the Active Directories in 2), above, the ones that belong to the same site (Tokyo) are 172.24.12.2 and 172.24.35.2.
Of these, the Active Directory that is the same subnet as SS-Tokyo is 172.24.12.2.
Therefore, this one will be accessed.
4) If access fails at step 3), above, the other Active Directory of the same site, 172.24.35.2, will be accessed.
5) If access fails at step 4), above, also, SSO-Osaka and SSO-Hakata will be accessed (the order will depend on the order of the Active Directories in DNS). Note, however, that this is an optional operation.
Logging into other domains at multi-domain
At multi-domain, if another domain is logged into, based on the site/ subnet information retrieved in the home domain, the Active Directories of the login destination domain/ KDC address list are computed. In the event that the domain controller IP addresses of other domains are outside of the site access range, and only the domain controller within the site is programmed for access, an error message will be displayed to the effect that the site information is incorrect.