CentOS 7: Moving Active Directory Domains

This goes hand-in-hand with this article:  http://www.mims.me/2016/05/centos-7-ad-authentication.html

1  First, we need to leave the first domain

realm leave -v EXAMPLE.COM

or

realm leave -v EXAMPLE.COM -U <domain admin account>

2.  Next, we need to join the new domain

realm join -v EXAMPLE.COM -U <domain admin account>

3.  If this worked, then go to the article mentioned at the top of the article to set various settings.

4.  I had a lot of trouble with various errors when trying to join my new domain, so here are some places to look if you have trouble.

/etc/samba/smb.conf  ... see if there are ANY references to the OLD domain or OLD DNS servers in this file and modify them to the NEW domain and NEW DNS servers.

If the below doesn't exist, don't add, but in my case it did, so make sure to modify.

[global]

#--authconfig--start-line--

# Generated by authconfig on 2015/08/04 13:08:52

# DO NOT EDIT THIS SECTION (delimited by --start-line--/--end-line--)

# Any modification may be deleted or altered by authconfig in future

   password server = ADDC1 ADDC2, ADDC3

security = user

   idmap config * : range = 16777216-33554431

   template shell = /bin/bash

   winbind use default domain = false

   winbind offline logon = false

#--authconfig--end-line--

___________________________________________________

/etc/krb5.conf  ... see if there are ANY references to the OLD domain and OLD DNS servers in this file and modify them to the NEW domain and NEW DNS servers

___________________________________________________

If it still doesn't work, run authconfig-tui and use the settings below (obviously modified for your domain):

5.  All you're looking for is that the computer successfully joined the domain.

CentOS 7: AD Authentication

In the past, I always installed pam_ldap and used that authentication method.  In Centos 7 and later, that just wasn't working.

Here's what I did to get user accounts to authenticate against Active Directory.

The RHEL guide for this is at:  https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ch-Configuring_Authentication.html

Here's the definitions of what I'm writing:

example.com - Active Directory domain-name
EXAMPLE.COM - realm-name
server.example.com - Linux computer you're joining to the Active Directory domain


1.  Install realmd (probably already installed) ... if not, yum install realmd

2.  realm discover example.com

# realm discover example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common
  login-formats: %U
  login-policy: allow-realm-logins

3.  Get the exact realm-name from the command above

4.  realm join <realm-name> -U <domain admin>

     realm join EXAMPLE.COM -U domainadmin

5.  reboot the linux box

6.  login to the linux box ... as root at this point

7.  Look back at step 2.  In login-formats, %U is specific ... that means just the userid needs to be entered when logging into linux instead of DOMAIN\userid ... step 8 shows how to do that.

8.  To login as just the userid instead of DOMAIN\userid

vi /etc/sssd/sssd.conf

use_fully_qualified_names = False

systemctl restart sssd

9.  realm discover example.com   ... make sure login-formats = %U

# realm discover example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common
  login-formats: %U
  login-policy: allow-realm-logins

10.  id <active directory login> (this is an active directory user ... NOT linux) ... you should get back the Active Directory information on the user

11.  Make the users you want sudo capable

vi /etc/group

wheel:x:10:aduser1,aduser2,aduser3

12.  Now the annoying part ... you MUST specify who's allowed to login via the AD userid

To allow ALL users:  realm permit --all

To allow a specific user:  realm permit user@example.com

13.  Reboot

14.  Login via console or ssh with your ad user

Outbound caller ID on IP office

To give credit where credit is due, this article comes from the website http://blogs.scansource.com/avaya-ip-office-caller-id-primer/.  It worked perfectly for me.  Copying it here in case their website goes down.

Avaya IP Office Caller ID Primer

This article explains how to control outbound caller ID on IP Office.

1)   PRI

1. Send out one DID for a group of phones
2. Send out different DIDs for each user

2)   SIP

1. Send out one DID for a group of phones
2. Send out different DIDs for each user

3)   Analog trunks

1) PRICaller ID on a PRI can be controlled using the ARS table or Incoming Call Routes. In most scenarios, the ARS should be used to send out one number for a group of phones, and Incoming Call Routes should be used to send out different Caller ID for each user.

a.   Send out one DID for a group of phonesTo send out one number for all phones, or a group of phones, edit the ARS table as follows.

ARS:

Please note that some carriers require the additional “i” character, which tags the call as national. In those scenarios the Telephone Number field will look like “1Nsi8642861234”.

Short Code:
In scenarios where one group of phones needs to send out one DID, and another group of phones needs to send out a different DID, direct the users to the appropriate ARS table with user short codes. In the example below, when this user dials 9 and any other digits, they are directed to the Line Group ID specified. In this case, the user will be directed to the ARS table 53:PRI, and any caller ID rules configured in that ARS table will be applied to the call. These short codes are applied at the system-wide or user short code level.

b.   Send out different DIDs for each userTo send out each individual user’s DID, the best practice is to edit the Incoming Call Routes for each user.

Incoming Call Route:In the Incoming Number field, add the character “i” (note: lower case) as a prefix, followed by the full ten-digit DID. The user associated with that Incoming Call Route sends the information configured in the Incoming Number field as Caller ID when dialing out. Since the Incoming Number field is matched from right to left, adding all ten digits to the Incoming Number field does not affect inbound routing.

2) SIP Trunks

a.   Send out one DID for a group of phonesTo send out one number for all phones, or a group of phones, the best practice is to add a SIP URI with the full ten-digit DID number that you would like to use for Caller ID in the Local URI, Contact, and Display Name fields.

User Short Code:

Direct the users to the appropriate ARS table with user short codes. In the example below, when this user dials 9 and any other digits, they are directed to the Line Group ID specified. In this case, the user will be directed to the ARS table 52:SIP. These short codes are applied at the system-wide or user short code level.

ARS:

Point the ARS codes to the Line Group ID of the appropriate SIP URI. The caller ID information configured in the SIP URI will be used for all calls routed through this ARS table.

b.   Send out different DIDs for each user

Use Internal Data:

User’s SIP Tab:
With “Use Internal Data” configured in the SIP URI, Caller ID is controlled based on the information configured in each user’s SIP Tab. In the example below, this user sends out “8642861234” as their DID. The ARS table must be configured to use the correct Outgoing Group ID (1 in this case).

3) Analog Trunks

Analog Caller ID is tied to the physical line and cannot be changed at the IP Office level. The line provider is responsible for configuring which Caller ID is sent out.