1. Introduction
Centrify Express is a
tool that will join Unix systems to Active Directory domain controllers. This
will allow the Unix teams to login with their Domain AD accounts instead of
local accounts.
Currently we are only
installing on Linux. Other Unix platforms will be incorporated in the future.
We plan to test AIX next.
High Level Steps for Rollout
Acquire Additional Active Directory Privileges
We are still in the
process of acquiring and getting approval for additional AD privileges. We are
requesting the ability to create our own computer objects when we join servers.
This will assist with our automation process and allow us to build servers more
quickly.
The workaround is to get
the AD Team to pre-create the computer objects by filling in their form. We
will do this method for now until the additional privileges get approved.
Join Servers to Active Directory
In this phase we will
join servers to Active Directory. Before doing a mass rollout we will pick a
couple dozen servers to join for a pilot phase. This will allow the teams to
see how the join works and how the client works. There will be several options
to join server but the preferred method will be BBSA. As mentioned above, until
we get approval for additional AD privileges we can fill the forms to get the
computer objects pre-created and ready for joining.
Convert Admins from Local Authentication to AD
Authentication
Once the servers are
joined, we can then start to convert users from local authentication to AD
authentication. To start we will do this user by user during the pilot phase.
We can decide if we want to do users in bulk after the pilot phase.
Clean Up Local Accounts
Once the users are
authenticating successfully with their AD accounts and there are no issues
requiring reverting back to the local account, then the local accounts can be
removed. Centrify does not need local accounts to work and there is no mapping
from local to AD. So we can keep /etc/passwd and /etc/shadow clean.
2. Centrify RPM
Installation on Linux
There are actually 3
ways you can install the RPM. The first way to do this in bulk will be BBSA
which is the preferred method. The second way is using YUM. The third way just
involves copying the rpm to the server and installing it manually.
The same RPM is
compatible with Red Hat 5 and 6.
2 YUM Install
The Server Engineering
team has created a custom channel for the Centrify rpm in the Satellite server.
This does require each server to be entitled to the channel. We will be working
on bulk entitlements so all servers should see this channel very soon. So if
you don’t see your system entitled as described below then let the Server
Engineering team know (Adrian Morrice and Tobin Sinclair).
You can verify if your
server is entitled by running this command:
yum repolist
You should see this
channel listed:
centrify-5-x86_64 CentrifyDC
(x86_64) RHEL5
You can also run this
command to verify the RPM is available.
# yum list CentrifyDC
Loaded plugins: katello, rhnplugin, security
Unable to read consumer identity
Available Packages
CentrifyDC.x86_64 5.1.0-497 centrify-5-x86_64
To install simply run
this command:
yum install CentrifyDC
2 Manual Install
This last option most
likely won’t be necessary but we will put it here just in case.
On the SSH Jump Server
we all have access to, you can find the rpm in this directory:
/ams/build/centrify/centrifydc-5.1.0-rhel3-x86_64.rpm
To install you need to
scp or sftp the rpm to the server and place in a temporary directory (e.g.
/tmp). Then run the following command on the server:
cd /tmp
rpm –ivh
centrifydc-5.1.0-rhel3-x86_64.rpm
3. Active Directory Groups
and Roles
For Centrify we will be
lining up the already defined roles and AD groups in BBSA. If a BBSA group
already provides full access to a server using the BBSA tool then it makes
sense to use the same roles in Centrify. We don’t need to maintain a separate
set of AD groups for Unix access.
So you need to ensure
your team members are in the role they need to be in. A complete list of roles
is in the table below. A Linux server will fall into one of these Categeries:
Deployment Services and
Support (Role:
Production RedHat Linux Support)
Premium
Support (Role:
HUB Infrastructure Platform)
Hub Engineering and
Support (Role:
HUB Infrastructure Platform)
Server
Engineering (Role:
Server Engineering)
Steps to configure
groups in Centrify are described in the Join section.
List of BBSA Roles:
|
Role
|
AD Group
|
|
Production RedHat Linux Support
|
ROL-BBSA_EI_RDH_SUP_L3_ADM
|
|
Production RedHat Linux Support
|
ROL-BBSA_EI_RDH_SUP_L2_ADM
|
|
Systems Operations Center
|
ROL-BBSA_EI_SOC_OPS_L2_ADM
|
|
Systems Operations Center
|
ROL-BBSA_EI_SOC_OPS_L1_ADM
|
|
Production AIX Support
|
ROL-BBSA_EI_AIX_SUP_L3_ADM
|
|
Production AIX Support
|
ROL-BBSA_EI_AIX_SUP_L2_ADM
|
|
Production Solaris Support
|
ROL-BBSA_EI_SOL_SUP_L3_ADM
|
|
Production Solaris Support
|
ROL-BBSA_EI_SOL_SUP_L2_ADM
|
|
Production HPUX Support
|
ROL-BBSA_EI_HPX_SUP_L3_ADM
|
|
Production HPUX Support
|
ROL-BBSA_EI_HPX_SUP_L2_ADM
|
|
Test Engineering
|
ROL-BBSA_EI_TEM_SUP_L3_ADM
|
|
Test Engineering
|
ROL-BBSA_EI_TEM_SUP_L2_ADM
|
|
Premium Support Team
|
ROL-BBSA_EI_PST_SUP_L3_ADM
|
|
Premium Support Team
|
ROL-BBSA_EI_PST_SUP_L2_ADM
|
|
HUB Infrastructure Platform
|
ROL-BBSA_EI_HIP_SUP_L3_ADM
|
|
HUB Infrastructure Platform
|
ROL-BBSA_EI_HIP_SUP_L2_ADM
|
|
Server Engineering
|
ROL-BBSA_EI_BUILD_SUP_L3_ADM
|
|
Server Engineering
|
ROL-BBSA_EI_BUILD_SUP_L2_ADM
|
The
above groups are mainly for system admin access. We will need to get additional
groups sorted out depending on who needs access to the servers. There will be
DBA groups and application groups. We will examine this on a server by server
basis.
4. Joining Linux to Active
Directory
The following section
will detail how to join a server to Active Directory. Joining is currently not
fully automated but there will be join job that can be run from BBSA. Currently
there will be a prerequisite to joining until full automation is approved.
4.1. Prerequisites
The goal is to have
enough privileges for the automation to automatically create the AD computer
object. This is not approved as of yet. So the prerequisite is that the
computer object be pre-created by the AD Team and that the sa_automation AD
account be given access to the computer object. The sa_automation account will
be used to join the servers.
In order to get the
computer object pre-created a form needs to be filled and sent to the AD Team
in an IR.
The DCE Server
Engineering team will be responsible for getting the computer objects created
and ready for joining.
IMPORTANT: Centrify
needs the hostname to resolve to office.adroot.test.net. So it may be necessary
to add this into the local host file as the first entry. This should not be
necessary if no other domain is specified in the hosts file.
e.g.
172.22.124.250 sat-bprad1.office.adroot.test.net
sat-bprad1.test.net sat-bprad1
4.2. Manual Join Procedures
The following steps need
to be performed on new joins. There is a script to automate these procedures.
IMPORTANT: It’s important to understand
that you will get a new UID. We can’t use your exising ID with this version of
the product we are going to use. The UID is assigned automatically and will be
the same on every server you login to.
1. Add all local accounts to
/etc/centrifydc/user.ignore.
This is done to protect the local accounts. It’s
important to understand that when Centrify is started and joined to AD then it
always come first in the authentication process. If a user is in the
user.ignore file then Centrify will ignore the account so local logins will
still work. Users need to be converted from local authentication to AD
authentication in a careful manner so we need to do this step when we first
join.
Each user is placed in the file on its own line.
e.g.
user1
user2
user3
etc…
etc…
2. Uncomment the auto.schema.allow.groups line in
/etc/centrifydc/centrifydc.conf and create the file
/etc/centrifydc/auto_user_groups.allow. Then add groups to the file.
Edit the centrify.conf file:
# vi /etc/centrifydc/centrify.conf
Uncomment this line:
auto.schema.allow.groups:
file:/etc/centrifydc/auto_user_groups.allow
Create the groups.allow file:
# touch /etc/centrifydc/auto_user_groups.allow
Add the following groups to the file (This may
change depending on what unix groups are classified/defined in AD)
rol-bbsa_ei_rdh_sup_l3_adm
rol-bbsa_ei_rdh_sup_l2_adm
rol-bbsa_ei_soc_ops_l2_adm
rol-bbsa_ei_soc_ops_l1_adm
rol-bbsa_ei_aix_sup_l3_adm
rol-bbsa_ei_aix_sup_l2_adm
rol-bbsa_ei_sol_sup_l3_adm
rol-bbsa_ei_sol_sup_l2_adm
rol-bbsa_ei_hpx_sup_l3_adm
rol-bbsa_ei_hpx_sup_l2_adm
rol-bbsa_ei_tem_sup_l3_adm
rol-bbsa_ei_tem_sup_l2_adm
rol-bbsa_ei_pst_sup_l3_adm
rol-bbsa_ei_pst_sup_l2_adm
rol-bbsa_ei_hip_sup_l3_adm
rol-bbsa_ei_hip_sup_l2_adm
rol-bbsa_ei_build_sup_l3_adm
rol-bbsa_ei_build_sup_l2_adm
rol-linux_wheel
3. Uncomment the auto.schema.groups line in
/etc/centrifydc/centrifydc.conf and create the file
/etc/centrifydc/auto_groups.allow. Then add groups to the file.
Edit the centrify.conf file:
# vi /etc/centrifydc/centrify.conf
Uncomment this line:
auto.schema.groups:
file:/etc/centrifydc/auto_groups.allow
Create the groups.allow file:
# touch /etc/centrifydc/auto_groups.allow
Add the following groups to the file (This may
change depending on what unix groups are classified/defined in AD).
rol-bbsa_ei_rdh_sup_l3_adm
rol-bbsa_ei_rdh_sup_l2_adm
rol-bbsa_ei_soc_ops_l2_adm
rol-bbsa_ei_soc_ops_l1_adm
rol-bbsa_ei_aix_sup_l3_adm
rol-bbsa_ei_aix_sup_l2_adm
rol-bbsa_ei_sol_sup_l3_adm
rol-bbsa_ei_sol_sup_l2_adm
rol-bbsa_ei_hpx_sup_l3_adm
rol-bbsa_ei_hpx_sup_l2_adm
rol-bbsa_ei_tem_sup_l3_adm
rol-bbsa_ei_tem_sup_l2_adm
rol-bbsa_ei_pst_sup_l3_adm
rol-bbsa_ei_pst_sup_l2_adm
rol-bbsa_ei_hip_sup_l3_adm
rol-bbsa_ei_hip_sup_l2_adm
rol-bbsa_ei_build_sup_l3_adm
rol-bbsa_ei_build_sup_l2_adm
rol-linux_wheel
4. Uncomment the pam.allow.groups line in
/etc/centrifydc/centrifydc.conf file and create the file
/etc/centrifydc/groups.allow file. Add the groups to the file that need login
access to the server.
Edit the centrify.conf file:
# vi /etc/centrifydc/centrify.conf
Uncomment this line:
pam.allow.groups:
file:/etc/centrifydc/groups.allow
Create the groups.allow file:
# touch /etc/centrifydc/groups.allow
Add the AD group of the team(s) that need access
to the server. Use the BBSA AD groups as described in the previous section.
Edit the file /etc/centrifydc/groups.allow:
# vi /etc/centrifydc/groups.allow
Add the groups and save the file. For multiple
groups ensure they are each on their own line.
5. Perform the join. Run the following command to
do the join. Remember that the computer object must be pre-created for this to
work until full automation is in place.
adjoin -u sa_automation@office.adroot.test.net
-p <pass> -V -w office.adroot.test.net
Watch the screen for any errors. There will be
some warning which should be okay.
6. You can run “adinfo --test” to ensure all the
connections to AD look good.
The BBSA Join Job
More to come…
Converting Linux Users
to Active Directory
Once the join is done
there should not be any impact to local logins. As described in the previous
section local logins are added to user.ignore so users will not have issues
logging in when Centrify is started. The next step is to convert users from local
authentication to AD authentication.
Manual Steps to Convert a User (If AD ID and
Unix ID are the same)
IMPORTANT: This is only necessary where
the user’s AD ID and Unix ID are the same. If they are different then there is
no conflict.
There are two main tasks
to do. Remove the user from the user.ignore file and fixing the permissions on
the user’s home directory.
1. Remove the user from
/etc/centrifydc/user.ignore.
2. In order to do the next steps you need to reload
and flush Centrify.
# adreload
# adflush -f
# adquery group (this will cache all the groups
we’ve defined as Unix groups)
3. Now you can query the AD UID the user shown
below. This command won’t work if the user is still in the user.ignore file.
# adquery user --uid <AD User ID>
4. Now that you have the AD UID you just need to
update the owner and groups permission on the user’s /home directory and all
the files in it. MAKE SURE TO UPDAT THE HIDDEN FILES TOO.
For example:
chown -R <AD UID>:<AD UID> <home
dir>
chown <AD UID>:<AD UID> .bashrc
chown -R 536928450:536928450 /home/amorric
The Script to Convert a
User (If AD ID and Unix ID are the same)
The DCE Server
Engineering team has made a script to easily convert a user. There is a second
script to convert back to the local accounts if the user has issues logging in.
IMPORTANT: This script is only
necessary where the user’s AD ID and Unix ID are the same. If they are
different then there is no conflict.
The script is located on
the SSH Jump server in the directory /ams/build/centrify. The scripts take one
argument which is the user ID and the scripts are called:
centrify_convert_to_ad.sh
<user ID>
centrify_convert_to_local.sh
<user ID>
Run these commands by
redirecting to a log file in case there is a large number of files that get
updated and the screen buffer is not large enough:
centrify_convert_to_ad.sh
<user ID> | tee <log file>
centrify_convert_to_local.sh
<user ID> | tee <log file>
Converting a User Where
the AD ID and Unix ID Are Different
When the AD ID and the
Unix ID are different there isn’t any conflict. So the user should not have any
issue logging in with the AD ID. When a user logs in for the first time to the
server and the ID does not exist locally then Centrify will automatically
create the user’s home directory and set permissions on the home directory
files using the AD UID.
The only task the user
will need to do is COPY the files from the local ID home directory to the AD ID
home directory and adjust the permissions to match the AD UID. Then you can
access your files normally. When satisfied the old home directory and local
account can be removed.
We haven’t planned any
scripting for this yet. But we can look into this if necessary.
Clean Up Local Accounts
Once the users are
satisfied that their AD accounts are working and there is no reason to revert
back to the local account then the local accounts should be removed. Centrify
does not need the local accounts to work so we can keep /etc/passwd and
/etc/shadow clean.
Adrian to test:
- Adrian to test userdel after conversion to AD
- possible script to remove from passwd and shadow
6. Sudo and Wheel
6.1. Sudo
There will be no impact
to what is in the sudoers file. This will still work no matter if the user is
logging in with the local account or AD account. Sudo privileges should remain
granted. This is assuming the AD ID and Unix ID are the same. If the user’s AD
ID is different from his/her Linux ID then the sudoers file will need to be
updated along with any local group access.
6.2. Wheel
The wheel group in Linux
is a group to restrict only system admins with the ability to switch to root.
Any accounts not in this group will not be able to switch to root. The wheel
group is part of the hardening guide we are currently testing and implementing.
Information Security is requesting that we implement this and now that we have
an AD integration tool this will be much easier to manage.
We will create a group
in AD called “rol-linux_wheel”. Any administrator who needs the ability to use
sudo and su will be required to be in this group.
This group will be
configured in /etc/pam.d/su as follows:
auth required pam_wheel.so
use_uid group=rol-linux_wheel
Also in /etc/sudoers we
will configure this line:
%rol-linux_wheel ALL=(ALL) NOPASSWD:
ALL
This group will not be
used for access to the servers. Access will be granted based on the BBSA AD
group you are in. Once you login you will be part of the wheel group which will
give you root access. The wheel group is not to be put into the Centrify
groups.allow file.
Centrify Troubleshooting
There are a couple
commands that provide a lot of information about the join status. This can help
us identify if there are any issues with the join.
6.3. adinfo
You can run adinfo to
give basic information about the join.
e.g.
# adinfo
Local host
name: centbccldvapp02
Joined to
domain: officeqa.adrootqa.test.net
Joined
as: centbccldvapp02.officeqa.adrootqa.test.net
Pre-win2K
name: centbccldvapp02
Current
DC: qalabofficedc03.officeqa.adrootqa.test.net
Preferred
site: <unavailable>
Subnet
site:
Warning!
Unable to locate computer's subnet site in Active Directory.
Please
advise your system administrator.
Zone: Auto
Zone
Last password set:
2013-10-26 12:56:07 EDT
CentrifyDC
mode: connected
Licensed Features:
Enabled
You can add --test to
have adinfo do some checking.
# adinfo --test
Domain Diagnostics:
Domain:
officeqa.adrootqa.test.net
DNS
query for: _ldap._tcp.officeqa.adrootqa.test.net
DNS
query for: _gc._tcp.officeqa.adrootqa.test.net
Testing
Active Directory connectivity:
Domain
Controller: off-yscwqadc-01.officeqa.adrootqa.test.net
ldap: 389/tcp
- good
ldap: 389/udp
- good
smb: 445/tcp
- good
kdc: 88/tcp
- good
kpasswd: 464/tcp
- timeout
ntp: 123/udp
- good
Domain
Controller: qalabofficedc02.officeqa.adrootqa.test.net
ldap: 389/tcp
- good
ldap: 389/udp
- good
smb: 445/tcp
- good
kdc: 88/tcp
- good
kpasswd: 464/tcp
- timeout
ntp: 123/udp
- good
Domain
Controller: qalabofficedc03.officeqa.adrootqa.test.net
ldap: 389/tcp
- good
ldap: 389/udp
- good
smb: 445/tcp
- good
kdc: 88/tcp
- good
kpasswd: 464/tcp
- good
ntp: 123/udp
- good
6.4. adcheck
adcheck provided a lot
of information about a domain and it’s trusts. It can be very useful to see if
something might be wrong.
# /usr/share/centrifydc/bin/adcheck -V
officeqa.adrootqa.test.net
adcheck (CentrifyDC
5.1.0-497)
Host Diagnostics
uname:
Linux centbccldvapp02 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012
x86_64
OS:
RedHatEnterpriseServer
Version:
6.3 (Santiago)
Number
of CPUs: 1
Linux
sanity checks
uname
says Linux centbccldvapp02 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT
2012 x86_64 x86_64 x86_64 GNU/Linux
osrev=rhel6
found
Perl: /usr/bin/perl
Samba
not found in $PATH.
Inspecting DNS
configuration
Configured
DNS servers are: -
10.225.224.17
(barrie-dns.test.net)
UDP
OK, response time = 0.0012
UDP
OK, response time = 0.0010
UDP
OK, response time = 0.0009
UDP
OK, response time = 0.0009
UDP
OK, response time = 0.0009
TCP
OK, response time = 0.0050
10.254.90.17
(scarb-dns.test.net)
UDP
OK, response time = 0.0039
UDP
OK, response time = 0.0035
UDP
OK, response time = 0.0051
UDP
OK, response time = 0.0041
UDP
OK, response time = 0.0034
TCP
OK, response time = 0.0064
IP Diagnostics
Local host name:
centbccldvapp02
Local IP Address:
10.193.46.236
FQDN host
name:centbccldvapp02.sysdev.adroot.test.net
look
for local ssh server - found SSH-2.0-OpenSSH_5.3
inspecting
OS type
inspecting
ssh configuration
sshd
-v says OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
Domain Diagnostics:
DNS
query for: _ldap._tcp.officeqa.adrootqa.test.net
Found
SRV records:
qalabofficedc03.officeqa.adrootqa.test.net:389
off-yscwqadc-01.officeqa.adrootqa.test.net:389
qalabofficedc02.officeqa.adrootqa.test.net:389
Found SRV records:
Probe
domain controller: off-yscwqadc-01.officeqa.adrootqa.test.net
LDAP
UDP port test OK, response time = 0.0173
NTP
port test OK, response time = 0.0102
server
off-yscwqadc-01.officeqa.adrootqa.test.net says the time is Mon Oct, 28
06:42:46 EDT
SMB
port test OK, response time = 0.0245
Kerberos
TCP port test OK, response time = 0.0100
Kerberos
UDP port test OK, response time = 0.0079
kpassword
TCP port test timeout, response time = 10.0102
Kpass
UDP port test OK, response time = 0.0000
LDAP
TCP port test OK, response time = 0.0104
Anonymous
LDAP bind to off-yscwqadc-01.officeqa.adrootqa.test.net
Retrieve
DC root object
Domain
Controller: off-yscwqadc-01.officeqa.adrootqa.test.net
Domain
controller type: Windows 2003
Domain
Name: officeqa.adrootqa.test.net
isGlobalCatalogReady: TRUE
domainFunctionality: 2
= (DS_BEHAVIOR_WIN2003)
forestFunctionality: 2
= (DS_BEHAVIOR_WIN2003)
domainControllerFunctionality:
2 = (DS_BEHAVIOR_WIN2003)
off-yscwqadc-01.officeqa.adrootqa.test.net
says we aren't in a site
Probe
domain controller: qalabofficedc02.officeqa.adrootqa.test.net
LDAP
UDP port test OK, response time = 0.0087
NTP
port test OK, response time = 0.0085
server
qalabofficedc02.officeqa.adrootqa.test.net says the time is Mon Oct, 28
06:43:06 EDT
SMB
port test OK, response time = 0.0238
Kerberos
TCP port test OK, response time = 0.0106
Kerberos
UDP port test OK, response time = 0.0106
kpassword
TCP port test timeout, response time = 10.0102
Kpass
UDP port test OK, response time = 0.0000
LDAP
TCP port test OK, response time = 0.0109
Anonymous
LDAP bind to qalabofficedc02.officeqa.adrootqa.test.net
Retrieve
DC root object
Domain
Controller: qalabofficedc02.officeqa.adrootqa.test.net
Domain
controller type: Windows 2003
Domain
Name: officeqa.adrootqa.test.net
isGlobalCatalogReady: TRUE
domainFunctionality: 2
= (DS_BEHAVIOR_WIN2003)
forestFunctionality: 2
= (DS_BEHAVIOR_WIN2003)
domainControllerFunctionality:
4
qalabofficedc02.officeqa.adrootqa.test.net
says we aren't in a site
Probe
domain controller: qalabofficedc03.officeqa.adrootqa.test.net
LDAP
UDP port test OK, response time = 0.0035
NTP
port test OK, response time = 0.0011
server qalabofficedc03.officeqa.adrootqa.test.net
says the time is Mon Oct, 28 06:43:27 EDT
SMB
port test OK, response time = 0.0016
Kerberos
TCP port test OK, response time = 0.0004
Kerberos
UDP port test OK, response time = 0.0007
kpassword
TCP port test OK, response time = 0.0003
Kpass
UDP port test OK, response time = 0.0000
LDAP
TCP port test OK, response time = 0.0004
Anonymous
LDAP bind to qalabofficedc03.officeqa.adrootqa.test.net
Retrieve
DC root object
Domain
Controller: qalabofficedc03.officeqa.adrootqa.test.net
Domain
controller type: Windows 2003
Domain
Name: officeqa.adrootqa.test.net
isGlobalCatalogReady: TRUE
domainFunctionality: 2
= (DS_BEHAVIOR_WIN2003)
forestFunctionality: 2
= (DS_BEHAVIOR_WIN2003)
domainControllerFunctionality:
2 = (DS_BEHAVIOR_WIN2003)
qalabofficedc03.officeqa.adrootqa.test.net
says we aren't in a site
Locating global catalogs
for ADROOTQA.TEST.NET from DNS.
DNS
query for: _gc._tcp.ADROOTQA.TEST.NET
Found
SRV records:
per-yscwqadc-02.percomqa.adrootqa.test.net:3268
sys-yscwqadc-01.sysdevqa.adrootqa.test.net:3268
qalabofficedc03.officeqa.adrootqa.test.net:3268
sac-bccwqadc-01.sacmcmqa.adrootqa.test.net:3268
qanesbittdc01.nesbittburnsqa.ca:3268
per-yscwqadc-03.percomqa.adrootqa.test.net:3268
per-yscwqadc-01.percomqa.adrootqa.test.net:3268
off-yscwqadc-01.officeqa.adrootqa.test.net:3268
har-yscwqadc-01.qaharrisbank.test.net:3268
sac-guawqadc-01.sacmcmqa.adrootqa.test.net:3268
pcd-wccwqadc-01.pcdqa.nesbittburnsqa.ca:3268
qanesbittdc03.nesbittburnsqa.ca:3268
qanesbittdc02.nesbittburnsqa.ca:3268
sac-guawqadc-02.sacmcmqa.adrootqa.test.net:3268
adr-yscwqadc-02.adrootqa.test.net:3268
adr-wccwqadc-01.adrootqa.test.net:3268
per-bccwqadc-01.percomqa.adrootqa.test.net:3268
qaibgdc01.ibgqa.adrootqa.test.net:3268
pcd-yscwqadc-01.pcdqa.nesbittburnsqa.ca:3268
sys-bccwqadc-01.sysdevqa.adrootqa.test.net:3268
sac-yscwqadc-01.sacmcmqa.adrootqa.test.net:3268
adr-yscwqadc-01.adrootqa.test.net:3268
har-wccwqadc-01.qaharrisbank.test.net:3268
adr-yscwqadc-03.adrootqa.test.net:3268
harmccwqadc-01.qaharrisbank.test.net:3268
qalabofficedc02.officeqa.adrootqa.test.net:3268
qaibgdc02.ibgqa.adrootqa.test.net:3268
Found SRV records:
Probe
GC: adr-wccwqadc-01.adrootqa.test.net
GC
port test OK, response time = 0.0004
Probe
GC: adr-yscwqadc-01.adrootqa.test.net
GC
port test timeout, response time = 10.0103
Probe
GC: adr-yscwqadc-02.adrootqa.test.net
GC
port test timeout, response time = 10.0103
Probe
GC: adr-yscwqadc-03.adrootqa.test.net
GC
port test timeout, response time = 10.0103
Probe
GC: har-wccwqadc-01.qaharrisbank.test.net
GC
port test OK, response time = 0.0008
Probe
GC: har-yscwqadc-01.qaharrisbank.test.net
GC
port test timeout, response time = 10.0102
Probe
GC: harmccwqadc-01.qaharrisbank.test.net
GC
port test timeout, response time = 10.0103
Probe
GC: off-yscwqadc-01.officeqa.adrootqa.test.net
GC
port test OK, response time = 0.0131
Probe
GC: pcd-wccwqadc-01.pcdqa.nesbittburnsqa.ca
GC
port test OK, response time = 0.0008
Probe
GC: pcd-yscwqadc-01.pcdqa.nesbittburnsqa.ca
GC
port test timeout, response time = 10.0102
stopped GC scan because
domain is big
DC performance table
qalabofficedc03.officeqa.adrootqa.test.net
udp response 3ms site=cwancentral
qalabofficedc02.officeqa.adrootqa.test.net
udp response 8ms site=cwancentral
off-yscwqadc-01.officeqa.adrootqa.test.net
udp response 17ms site=cwancentral
symmetry
test on 10.225.224.17
get
srv list for domain ok 3 entries
symmetry
test on 10.254.90.17
get
srv list for domain ok 3 entries
Retrieving
site information from qalabofficedc03.officeqa.adrootqa.test.net
compare the clocks on
all domains to see if they are all synchronized.
Domain
off-yscwqadc-01.officeqa.adrootqa.test.net
qalabofficedc02.officeqa.adrootqa.test.net
qalabofficedc03.officeqa.adrootqa.test.net
are
synchronized. (The difference between them is less than 5 seconds.)
OSCHK :
Verify that this is a supported
OS :
Pass
PATCH :
Linux patch check :
Pass
PERL :
Verify perl is present and is a good
version :
Pass
SAMBA :
Inspecting Samba
installation :
Pass
SPACECHK : Check if
there is enough disk space in /var /usr
/tmp : Pass
HOSTNAME : Verify
hostname
setting :
Pass
NSHOSTS :
Check hosts line in
/etc/nsswitch.conf :
Pass
DNSPROBE : Probe DNS
server
10.225.224.17 :
Pass
DNSPROBE : Probe DNS
server
10.254.90.17 :
Pass
DNSCHECK : Analyze basic
health of DNS
servers :
Pass
WHATSSH : Is
this an SSH that DirectControl works well
with : Pass
SSH :
SSHD version and
configuration :
Warning
:
You are running OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010.
:
:
This version of OpenSSH does not seem to be configured for PAM,
:
ChallengeResponse and Kerberos/GSSAPI support.
:
To get Active Directory users to successfully login,
:
you need to configure your OpenSSH with the following options:
:
(display the ones we identified were not set)
:
ChallengeResponseAuthentication yes
:
UsePAM Yes
:
:
Centrify provides a version of OpenSSH that's configured properly
:
to allow AD users to login and provides Kerberos GSSAPI support.
:
:
If you install Centrify Express or Centrify Suite
:
Standard or Enterprise Edition, the Centrify build of
:
OpenSSH will be installed automatically. Alternatively
:
you may choose individual Suite packages to install
:
with the Custom install option.
DOMNAME :
Check that the domain name is
reasonable :
Pass
ADDC :
Find domain controllers in
DNS :
Pass
ADDNS :
DNS lookup of DC off-yscwqadc-01.officeqa.adrootqa.test.net: Pass
ADPORT :
Port scan of DC off-yscwqadc-01.officeqa.adrootqa.test.net : Warning
:
One or more ports failed to respond correctly. Either:
: a)
the DC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: kpass(464)/tcp
- timeout
ADDNS :
DNS lookup of DC qalabofficedc02.officeqa.adrootqa.test.net: Pass
ADPORT :
Port scan of DC qalabofficedc02.officeqa.adrootqa.test.net : Warning
:
One or more ports failed to respond correctly. Either:
: a)
the DC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: kpass(464)/tcp
- timeout
ADDNS :
DNS lookup of DC qalabofficedc03.officeqa.adrootqa.test.net: Pass
ADPORT :
Port scan of DC qalabofficedc03.officeqa.adrootqa.test.net : Pass
ADDC :
Check Domain
Controllers :
Pass
ADDNS :
DNS lookup of DC adr-wccwqadc-01.adrootqa.test.net :
Pass
GCPORT :
Port scan of GC adr-wccwqadc-01.adrootqa.test.net :
Pass
ADDNS :
DNS lookup of DC adr-yscwqadc-01.adrootqa.test.net :
Pass
GCPORT :
Port scan of GC adr-yscwqadc-01.adrootqa.test.net :
Warning
:
One or more ports failed to respond correctly. Either:
: a)
the GC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: gc(3268)/tcp
- timeout
ADDNS :
DNS lookup of DC adr-yscwqadc-02.adrootqa.test.net :
Pass
GCPORT :
Port scan of GC adr-yscwqadc-02.adrootqa.test.net :
Warning
:
One or more ports failed to respond correctly. Either:
: a)
the GC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: gc(3268)/tcp
- timeout
ADDNS :
DNS lookup of DC adr-yscwqadc-03.adrootqa.test.net :
Pass
GCPORT :
Port scan of GC adr-yscwqadc-03.adrootqa.test.net :
Warning
:
One or more ports failed to respond correctly. Either:
: a)
the GC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: gc(3268)/tcp
- timeout
ADDNS :
DNS lookup of DC har-wccwqadc-01.qaharrisbank.test.net :
Pass
GCPORT :
Port scan of GC har-wccwqadc-01.qaharrisbank.test.net :
Pass
ADDNS :
DNS lookup of DC har-yscwqadc-01.qaharrisbank.test.net :
Pass
GCPORT :
Port scan of GC har-yscwqadc-01.qaharrisbank.test.net :
Warning
:
One or more ports failed to respond correctly. Either:
: a)
the GC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: gc(3268)/tcp
- timeout
ADDNS :
DNS lookup of DC harmccwqadc-01.qaharrisbank.test.net :
Pass
GCPORT :
Port scan of GC harmccwqadc-01.qaharrisbank.test.net :
Warning
:
One or more ports failed to respond correctly. Either:
: a)
the GC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: gc(3268)/tcp
- timeout
ADDNS :
DNS lookup of DC off-yscwqadc-01.officeqa.adrootqa.test.net: Pass
GCPORT :
Port scan of GC off-yscwqadc-01.officeqa.adrootqa.test.net : Pass
ADDNS :
DNS lookup of DC pcd-wccwqadc-01.pcdqa.nesbittburnsqa.ca :
Pass
GCPORT :
Port scan of GC
pcd-wccwqadc-01.pcdqa.nesbittburnsqa.ca : Pass
ADDNS :
DNS lookup of DC
pcd-yscwqadc-01.pcdqa.nesbittburnsqa.ca : Pass
GCPORT :
Port scan of GC
pcd-yscwqadc-01.pcdqa.nesbittburnsqa.ca : Warning
:
One or more ports failed to respond correctly. Either:
: a)
the GC is offline
: b)
a firewall is preventing access to a port
:
The following is a list of failed ports:
: gc(3268)/tcp
- timeout
ADGC :
Check Global Catalog
servers :
Pass
DCUP :
Check for operational DCs in officeqa.adrootqa.test.net :
Pass
DNSSYM :
Check DNS server
symmetry :
Pass
ADSITE :
Check that this machine's subnet is in a site known by AD :
Failed
:
This machine's subnet is not known by AD.
:
We guess you should be in the site cwancentral.
TIME :
Check clock
synchronization :
Pass
ADSYNC :
Check domains all
synchronized :
Pass
1 serious issue was
encountered during check. This must be fixed before proceeding
9 warnings were
encountered during check. We recommend checking these before proceeding
6.5. adquery
adquery is a useful
command for getting group and user information from AD.
To get a dump of a user
you can run:
adquery user -j
<user>
To get a dump of a group
you can run:
adquery group - j
<group>
To display help:
adquery --help
To get a UID or GID:
adquery user --uid
<user>
adquery group --gid
<group>
To get the users’
groups:
adquery user --groups
<user>
To get a group’s
members:
adquery group --members
<group>