0% found this document useful (0 votes)
43 views10 pages

B08 Active Directory RADIUS A7.15

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views10 pages

B08 Active Directory RADIUS A7.15

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

ASTRO® 25 RELEASE 7.

15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Section B08 Active Directory RADIUS


This section describes Active Directory and RADIUS, the capabilities they support, and
other considerations that you must take into account when you design a system with these
features.

NOTE: ASTRO® 25 K1/K2 configurations do not have Active Directory Domain


Controllers, and will not support centralized authentication. All systems that have
Domain Controllers also have RADIUS support by default.

NOTE: For each new release, a new System Planner document is generated. When
designing ASTRO® 25 radio systems, use the latest version.

MN000604A01-B Page 1 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Chapter 1 Description

Domain Controllers are a baseline part of all ASTRO® 25 7.X systems. It hosts Active
Directory and RADIUS. It is used to provide central authentication, authorization, and
accounting of users’ login into Microsoft Windows® and Linux devices. As part of system
configuration, a device is joined to the Active Directory by Domain Administrator. This
creates mutual trust between the server and the client device. Domain Controllers also host
DNS service in the ASTRO system and are the sole DNS providers for the system.

Active Directory allows for users and groups to be created and managed in one centralized
location. Common group security policies can be uniformly applied to user accounts. Users
can use the same name and password to log into any device that is part of the Active
Directory domain and RADIUS devices. Also, some level of accounting is provided as users
authenticate through one centralize authority.

Remote Authentication Dial In User Service (RADIUS) is also a required part of all ASTRO®
25 7.X systems. RADIUS server is hosted by the Microsoft Windows® 2008 Domain
Controller server. It too, is used to provide central authentication of users. This protocol is
different from Kerberos and LDAP protocols that Active Directory uses. It allows for
centralized authentication of a different set of devices, mainly devices with non -commodity
operating system that could not be natively integrated with the Active Directory.

RADIUS service does not provide the same level of user authorization capabilities as native
Active Directory authentication. It shares the same user database as Active Directory, so
single user account can be used to authenticate on the commodity OS devices and non –
commodity OS devices.

Active Directory and RADIUS form the basis upon which other features are built. For
example, the 802.1x Port-Based Network Access Control features are built upon Active
Directory and RADIUS.

Microsoft Windows® and Linux OS devices ship from Motorola without default local user
interactive OS level accounts, except for the all powerful administrator account. All these
devices need to be joined to the Active Directory domain, and have user accounts created in
Active Directory.

Embedded OS devices may have some default local interactive accounts in addition to the
all powerful administrative account.

MN000604A01-B Page 2 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Table 1 Devices/Platforms Supported by Active Directory and RADIUS

Active Directory Authentication RADIUS Authentication


Firewalls
Devices running the Microsoft Windows® OS KVL
Devices running the RHEL OS MOSCAD NFM embedded OS devices
PTP 600 and 800 Radios (for Backhaul
Network)
RF site equipment Routers
SmartX
Switches
Telephony Media Gateway
Terminal Server
VPM

NOTE: The “Equipment Supported” section of the Centralized Authentication section


of this System Planner contains a table identifying all of the different products in the
radio network, and what type of authentication system they use. Devices stating their
authentication method as Active Directory or RADIUS are part of the list of devices
supported by this feature.

Capabilities and Constraints

The capabilities associated with Active Directory and RADIUS are as follows:
 Multiple points for provisioning users and groups for the devices listed above
 Central management of operating system specific configuration (e.g., enabling
and disabling services) for Windows.

The following constraints exist with Active Directory and RADIUS in ASTRO® 7.X systems:
 Only the zone-level Domain Controllers are RADIUS provisioning points
although the RADIUS server in the UCS subnet acts as a secondary RADIUS
server for all Zones.

MN000604A01-B Page 3 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Chapter 2 Technical Overview

Active Directory
Active Directory is Microsoft’s implementation of a directory service and authentication
system. It uses LDAP for directory services and a combination of LDAP and Kerberos for
secure authentication. It is based on the concept of domains. Each domain contains various
components. These components are managed by the same set of administrators, or have the
same set of security policies, or provide the same set of services.

Active Directory domain names are similar to DNS domain names. In fact, Active Directory
uses DNS to store some information used by clients to find services tied to Active Directory.
While Active Directory domain names tend to align with DNS domain names, they can be
separate from the DNS domain of a given computer. For example, a computer may be
located in the DNS domain, zone3, but belong to the Active Directory domain,
ASTRO.custY. DNS domains and AD domain namespace are disjoint. A single AD domain
traverses multiple RNI Zones and hence multiple DNS domains. Since all of the hostnames
are not unique across RNI zones and Microsoft uses only the short hostname for identifying
client computers, they need to be joined into the domain using unique names. Hence a
server like Zone Controller that has a short hostname of zc01 in all zones is joined into the
domain as z00Zzc01 where Z is the zone number.

Active Directory service runs on servers known as Domain Controllers (DCs). All Domain
Controllers are peers of each other. In other words, operations performed on one Domain
Controller can be performed on its peers as well. Active Directory has mechanisms built into
it that keep each Domain Controller in sync.

In ASTRO® 7.X, Active Directory is set up as single AD domain with multiple Domain
Controllers for improved AD service availability. All Domain Controllers are part of single
AD domain, with all AD data automatically replicated between Domain Controllers. There
is one zone-level Domain Controller in each zone, and one at the system-level. The primary
Domain Controller is the zone-level one, local to the device. The fallback Domain Controller
is always the one at the system-level.

Changes to AD domain user account data take up to 30 minutes to fully replicate between
all Domain Controllers. It’s advised to make these changes in the local Domain Controller
for a given zone so that they are available immediately for use.

Optionally, a console site can have local Domain Controller for improved AD service
availability in scenarios of lost connectivity to the master site.

Figure 1 gives an example of the Active Directory setup in ASTRO® 7.X.

MN000604A01-B Page 4 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Figure 1 Active Directory Architecture

z0 0 7n m d0 2 5o p1

z0 0 1n m d1 0 9a is2
Jo h n o p e ra to rs
z0 0 7n m d 0 0 1o p1
B ill
cu sto m e r d e fin e d A ctive D ire cto ry
M a ry m a n a g e rs
d o m a in (o p tio n a l)

z0 0 1zc0 1 z0 0 2zc0 1

z0 0 1n m d0 0 1o p1 z0 0 1n m d1 0 9a is2

z0 0 1n m d 1 0 9a is2
U cs0 1.u cs U cs0 2.u cs

S yste m w id e A ctive D ire cto ry d o m a in

z0 0 1n m d 0 0 2a is2

z0 0 1n m d 0 0 2o p 1
S ite-L e ve l A ctive D ire cto ry d o m a in
(n m d2 .zo n e1 ) (o p tio n a l)

If a Domain Controller fails, this tends to be catastrophic. For that reason, there should be at
least two (2) Domain Controllers per Active Directory domain. This means that if you lose a
single Domain Controller, AD service is still available.

For Single Zone Non-Redundant configuration, there are two Domain Controllers, one in
the zone subnet and one in the UCS subnet. These are virtual machines (VM) on a single
physical server. For Single Zone Redundant configuration, there are two Domain

MN000604A01-B Page 5 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Controllers as virtual machines on separate physical servers. For Multi-Zone Capable, the
master site that has the UCS subnet co-located with it has the same setup as the Single Zone
Redundant. The other zones that may exist in a Multi-Zone Capable configuration contain a
Domain Controller as a virtual machine.

NOTE: In the case of a customer creating a separate AD domain for agency


partitioning, it is required that the domain controllers belonging to the main system
wide domain are not removed from any of the RNI zones. For each additional AD
domain that the customer adds, ASTRO recommendation is to have at least two
domain controllers for redundancy. Installation procedures are not provided by
engineering.

Customer creates domain user accounts and computer accounts will be migrated.

Joining all Windows and UNIX RNI devices to the AD domain can be time consuming. For
this reason service automation interface is being provided to do it on Windows and Linux
devices remotely via automated scripts.

RADIUS
Most network devices use Remote Authentication Dial-In User Service (RADIUS) for
authentication. The ASTRO® 25 7.X systems use the Microsoft Network Policy Server (NPS)
software to provide the RADIUS service. The NPS software is installed on each Domain
Controller at the master site. NPS is configured to use Active Directory for user
authentication. This allows the same set of servers to provide centralized authentication and
management for the radio network.

In ASTRO 7.9 both Read-Only and Read-Write groups are defined and users can be
associated with either group.

Clients are configured to communicate with a primary RADIUS server and a secondary
RADIUS server. This allows for greater availability when using RADIUS authentication on
devices like the routers and switches. The RADIUS server in the zone is the primary
RADIUS server and the RADIUS server on the UCS DC is the secondary RADIUS server.
This allows for a consistent client configuration. As of A7.9, NPS is the only RADIUS server
and there is no separate RADIUS server on the CSMS for Terminal servers.

NOTE: Although the RADIUS server on the UCS DC acts as the secondary RADIUS
server for each RNI zone RADIUS server, it should not be used as a management
point for any RADIUS data. RADIUS data should be changed only on the Zone level
RADIUS server and it gets replicated (one way) to the UCS RADIUS server. But any
changes to the RADIUS policies will have to be applied manually at the UCS
RADIUS server and will not be replicated as part of normal RADIUS client data.

MN000604A01-B Page 6 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Equipment Functional Descriptions

System-Level Domain Controllers

The system-level Domain Controllers (henceforth just referred to as system-level DCs) are
the top of the Active Directory forest. They contain some of the special roles related to
Active Directory Administration called FSMO roles. In addition, the System level Domain
Controller acts as a fallback DNS and RADIUS server for all of the Zone-based devices.

By default, in all system configurations except K Cores, there is a single system level DC. A
customer can optionally buy a second system level DC (also deployed as a virtual machine
only) that is a on a separate physical server. To effectively use the additional DC, some DNS
client configurations have to be changed because of DNS and AD being hosted on the same
server. AD service has a strong dependency on DNS for proper functioning and can resolve
fallback servers only if DNS is available.

Zone-Level Domain Controllers

The zone-level Domain Controllers (henceforth just referred to as zone-level DCs) are the
DCs at each RNI zone. They contain all of the user and computer data that is on every other
DC in the system. The zone-level DCs are also DNS servers hosting the RNI DNS domain
(and sub-domains) and primary RADIUS server for all of the zone RADIUS clients.

In a Single Zone Non-Redundant configuration, there is a single zone-level DC residing on


the Zone Network Management (ZNM) subnet. It is a virtual machine residing on the same
virtual server as the single system-level DC. In a Single Zone Redundant configuration, the
zone-level DC is a virtual machine residing on a different virtual server than the system-
level DC.

Multi-Zone Capable configuration is slightly different. In a single zone Multi-Zone Capable


configuration, the DCs are set up identical to the Single Zone Redundant configuration. In a
multi-zone system, the RNI zone that contains the UCS subnet has DCs that are virtual
machines, just like in the single zone Multi-Zone Capable configuration. The other RNI
zones have DCs that are virtual machines running on virtual servers.

Additional zone-level DCs can be added. If a Console site is generating a lot of traffic to the
master site and is impacting the network connection, one or two DCs that belong to the
same AD domain can be added to that site to reduce the network traffic between the site
and the master site. If a customer wants sub-domains at a site then, either Motorola service
or customer IT has to step in to create those delegated AD domains.

Figure 2 shows where domain controllers for a given zone Active Directory domain might
be located.

MN000604A01-B Page 7 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Figure 2 DC Locations

As a rule of thumb, the Table 1 can be used to determine if additional zone-level DCs are
needed at any given Console site:

Table 1 Extra Zone-Level DCs at MCC 7500 Site

Zone-Level DCs at Number of Console


Console Site Devices at Site

0 <15
1 15 to 30
2 >30

MN000604A01-B Page 8 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

NOTE: These extra zone-level DCs are ONLY needed if it is determined there is
impact to the network. If the network looks like it is fine, then these extra DCs are not
needed.

Site-Level Domain Controllers

NOTE: Site-Level Domain Controllers are optional. They are for load balancing that a
customer can choose to have if it has large number of consoles. They are not required
to support the radio aspect of agency partitioning and installation procedures for
these are not provided by engineering. They are expected to setup on their own with
help from Motorola support

Site-level DCs are the same as the zone-level DCs located at a given Console site, except for
the lack of RADIUS service at the site level DCs. Zone-level DCs located at a Console site are
still domain controllers for the system wide AD domain. Site-level DCs located at a Console
site are domain controllers only for that particular Console site.

For Single Zone Non-Redundant configuration, any site that has its own Active Directory
domain can have a single DC or multiple DCs according to the customer needs for
redundancy.

MN000604A01-B Page 9 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal
ASTRO® 25 RELEASE 7.15 SYSTEM PLANNER SECTION B08 ACTIVE DIRECTORY RADIUS

Hardware

As was mentioned earlier, there is a system-level Active Directory domain controller and a
zone-level Active Directory domain controller. Therefore, at a minimum, the system
requires two (2) Domain Controllers.

Table 2 identifies the number of pieces of server hardware required for a given system:

Table 2 Hardware Required for Domain Controllers

Type of System Number of Virtual Servers

Single Zone Non-Redundant 1

Single Zone Redundant 2

Multi-Zone Capable 2
(single zone)

Multi-Zone Capable 1+ Z
(multiple zones)

The “1+ Z” equation in the Multi-Zone Capable (multiple zones) row is the number of zones
(Z), plus 1 for the DC in the UCS.

MN000604A01-B Page 10 of 10 June 2015


Section B08 Active Directory RADIUS
Motorola Solutions Internal

You might also like