AWS Console has its own authentication/authorization directory using IAM users, roles and policies. On top of that, they also offer multi-factor authentication, so your logins are much more secure. But, I wanted to see how I can use Okta for SSO between my AD domain at home and AWS. The setup is very simple as you can see from this diagram.
On the left side, AWS is missing – but you get the point. In my case, I’ll have two AD groups, AWS Full Admin and AWS Read Only. I also have two AD users, admin.user and ro.user. If you haven’t integrated your AD with Okta it’s time to do so.

Okta

Go to the Okta dashboard and from the menu go to Directory | Directory Integrations.

Click on Add Active Directory and proceed so you can download an agent that you have to install on a member server with at least 8GB RAM. You can also install it on a domain controller, which I did in my lab, but I guess it’s not recommended. You’ll see this page telling you that Okta is waiting for your AD to connect.

Go ahead and install the agent. You’ll be prompted to specify the domain name (andreev.local in my case), create a service account OktaService or choose an existing one, choose a proxy to connect to Okta servers over HTTPS (if needed) and finally you have to specify your Okta domain, e.g. the prefix for your Okta landing page, https://company.Okta.com. You have to type -company-.

Once the service starts and authenticates with your Okta admin account to the Okta servers, your dashboard page will change asking you to specify what OUs in your AD you want to sync. Choose the OUs and choose your Okta username format.

In my case I’ll use UPN which is username@andreev.local, but you can choose e-mail if your have a valid e-mail specified for the users, e.g. username@google.com or the SAM account which is your login that you use for AD, e.g. username. See below.

Click Next and unless you have some non-standard AD attributes that you want to map, it’s safe to proceed with the defaults. Under the settings for the AD in Okta, you can choose the scheduled interval for the AD sync. By default, this sync is disabled. To test the integration, go to the settings page of your AD in Okta, choose Test Delegated Authentication (bottom right) and enter the username and password for an AD account that you know it’s synced with Okta.

You can also test the integration if you go to https://-company-.okta.com and log in with a synced AD user.

Okta app for AWS

Before we move to AWS part, click on Applications from the menu and click on Add Application menu. Type Amazon Web Services and select the app. Do not use AWS Console app, that’s a different one.

Click Add and you can leave the settings under General Settings or change it to AWS Console. Click Next and on the next screen, use SAML 2.0
Click on the Identity Provider Metadata link and download the file. You’ll need this for later.

Click Done and once this part is completed, we can go to AWS Console and configure AWS IAM and then come back to Okta.

AWS Console

Log to the AWS Console with an account with sufficient rights to create IAM polices, roles and users. Go to IAM and then Identity Providers on the left side. Click Create Provider and choose SAML for Provider Type, type a description (e.g. OKTA) and choose the metadata file that you’ve just downloaded.

Click on Next Step and then Create. Click on the entry that you just created and make a note of the ARN. You’ll need this later.

IAM

We’ll create two new roles based on existing AWS policies for full admin access and read only access. Go to IAM | Roles and click on Create Role. Click on SAML 2.0 federation, choose the SAML provider that we just created, select Allow programmatic and AWS Management Console access and click on Next: Permissions.

You can create your own policy if you want by clicking on Create policy or choose an existing one like I did by filtering the Read Only policies. Click on Next: Tags after.

You can tag your role and click Next: Review after…and finally you can create the role.

Do the same again IAM | Roles | SAML, but this time create a full admin role named rolFullAdminAccess (filter the policies by Administrator).
Let’s connect AWS and Okta now, but creating a user that will be able to list the roles. Go to IAM | User and click on Add user. Name your user and allow Programmatic access only.

Click on Create policy. This will open a new window. Do not close the previous one.

Click on the JSON tab and paste this policy. Then click Review policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
          "Effect": "Allow",
          "Action": [
              "iam:ListRoles",
              "iam:ListAccountAliases"
          ],
          "Resource": "*"
        }
    ]
}

Name your policy and click on Create policy.

Go back to the previous tab and click on the refresh button, right off the Create policy button. Then filter the policy and assign it. Click Next: Tags.

Proceed to create the user, but make sure you download the CSV file with the credentials for this user.

Okta – app config

Go back to Okta and click on the Sign On tab and then Edit.

Scroll down a little bit and paste your ARN value (the one that you got from AWS earlier) under Identity Provider ARN (Required only for SAML SSO. It’s under IAM | Providers | -your-provider in AWS. Click Save after.
Click on the Provisioning tab next to Sign On and click on Configure API Integration. Click the checkmark, then copy and paste the access key and the secret from the CSV file from AWS. Click Test API Credentials and if everything is OK, click on Save.

Under Provisioning make sure that Create Users and Update User Attributes are enabled.
Finally, go to the Assignments tab and select Groups. Then, click the green button Assign and choose Assign to Groups.

You will see your groups here, select the first one and click the Assign button.

You will see your roles there. Select the admin role and Save.

Do the same for the other group and role and pretty much you are all set. Open a new browser and this time log as one of the users, in my case I am logging as admin.user to https://mycompany.okta.com.

You’ll get a note that you have a new app assigned.

If you click on the app icon, you’ll get logged in to the AWS console without any passwords.

Multi-factor authentication

While the above setup looks good, you still need MFA to make things even more secure. Go to the app settings in Okta and click on the Sign On tab then click Edit.

Scroll all the way down and click on Add Rule.

Name the rule however you want and scroll all the way down.

Click on Prompt for fact and choose whatever you want from the settings.

Once configured, when you log in to your Okta dashboard, you’ll get in without prompted for MFA, but when you click on the AWS Console app, you’ll get redirected to AWS to configure your MFA. You can use the Okta mobile app for MFA or Authy which I prefer. This is because we configured the MFA to occur on the AWS level, not on Okta level.

This post is a slight modification of the official wiki for setting up Samba as an AD Domain Member.

In my lab, I built a Windows 2012R2 domain controller/DNS and a CentOS 7.1 VM running Samba 4.2.10.
My Windows domain is kdomain.local and the NETBIOS name is MYDOMAIN. They are on the same subnet and the IP of the CentOS VM is in the DNS. Let’s verify the prerequisites before we install Samba. Make sure that everything checks out.

Check the hostname first.

hostname
centos7dd.kdomain.local

If you need to change the hostname, use hostnamectl set-hostname your_hostname
Make sure your resolver points to a valid domain controller.

cat /etc/resolv.conf
search kdomain.local
nameserver 192.168.1.19

Check your IP.

ip addr show | grep inet
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
    inet 192.168.1.6/24 brd 192.168.1.255 scope global eno16777736

Check the resolving. dc03 is my domain controller, centos7dd is my CentOS member server, the one that I am configuring.

host -t A dc03.kdomain.local
dc03.kdomain.local has address 192.168.1.19
host -t A centos7dd.kdomain.local
centos7dd.kdomain.local has address 192.168.1.6

If you get an error that host is an unknown command, install bind-utils with yum install bind-utils. You don’t have to, but make sure that all IPs and resolving works fine.
Some more checks, to see if you don’t have something messed up in /etc/hosts file.

getent hosts centos7dd
192.168.1.6     centos7dd.kdomain.local

Now it’s time to install samba.

yum install samba samba-devel samba-winbind samba-winbind-clients

Before you go further, you need to know what’s realm, NETBIOS and workgroup in Samba terms. They are kind of misleading as you can see below from the samba config file. On the domain controller, open up a command prompt and type:

set | find  "DOMAIN"
USERDNSDOMAIN=KDOMAIN.LOCAL
USERDOMAIN=MYDOMAIN
USERDOMAIN_ROAMINGPROFILE=MYDOMAIN

My domain is KDOMAIN.LOCAL and the NETBIOS domain name is MYDOMAIN. The hostname of my domain controller is DC03, but that’s irrelevant.
Find where the config file is stored.

smbd -b | grep CONFIGFILE
   CONFIGFILE: /etc/samba/smb.conf

Rename the original file as something else and edit smb.conf so it’s an empty file. Add the following lines there.

[global]
        netbios name = centos7dd
        realm = KDOMAIN.LOCAL
        workgroup = MYDOMAIN
        security = ADS
        winbind enum groups = Yes
        winbind enum users = Yes
        winbind nss info = rfc2307
        idmap config *:range = 2000-9999
        idmap config * : backend = tdb

Now, you can join the VM to the domain.

net ads join -U administrator
Enter administrator's password:
Using short domain name -- MYDOMAIN
Joined 'CENTOS7DD' to dns domain 'kdomain.local'

Let’s make sure that Samba starts now and on each boot.

systemctl start smb.service
systemctl start nmb.service
systemctl start winbind.service
systemctl enable smb.service
systemctl enable nmb.service
systemctl enable winbind.service

Make sure you get the domain users and groups back.

wbinfo -u
MYDOMAIN\administrator
MYDOMAIN\guest
MYDOMAIN\klimenta
MYDOMAIN\krbtgt

wbinfo -g
MYDOMAIN\winrmremotewmiusers__
MYDOMAIN\domain computers
MYDOMAIN\domain controllers
MYDOMAIN\schema admins
MYDOMAIN\enterprise admins
....

Now, edit /etc/nsswitch.conf and modify these three lines. Just add winbind after sss for passwd , shadow and group entries, so it looks like this. Don’t change the lines where it says #passwd: db files nisplus nis.

passwd:     files sss winbind
shadow:     files sss winbind
group:      files sss winbind

Now, do getent passwd and getent group. You should recieve both local and domain users and groups as output.

Finally, if you have a firewall, add an exception for Samba services.

firewall-cmd --permanent --zone=public --add-service=samba
firewall-cmd --reload

At this point, you’ll have the OS fully configured as a domain member, but you still can’t log in to CentOS with a domain account. In order to do that, we’ll have to run authconfig-tui. NOTE: For CentOS 8 use authselect select winbind --force.

authconfig-tui

Make sure these options are set.

…and these. You don’t have to join to the domain, just select OK.

This utility will change a lot of files, especially those in /etc/pam.d directory and it will also change smb.conf. Restart the winbind service in order for these changes to take effect.

systemctl restart winbind.service

Make sure you have these lines in smb.conf.

template shell = /bin/sh
template homedir = /home/%D/%U

Reload Samba config.

systemctl reload smb.service

Because of the template homedir directive above, all home directories for the domain users will be under /home/MYDOMAIN (or whatever domain you have).
Finally, create the home dir and log as the user.

mkdir -p /home/MYDOMAIN/klimenta
cd /home/MYDOMAIN
chown -R klimenta@kdomain.local klimenta

Now, you can log as the domain user.

login as: klimenta@kdomain.local
klimenta@kdomain.local@192.168.1.6's password:
Last login: Wed Sep  7 11:08:10 2016 from 192.168.1.101
-bash-4.2$ pwd
/home/MYDOMAIN/klimenta

What if we want to share our home or some other folder on the CentOS server? We have to add a config change in smb.conf file. I’ll explain how to share the home folder. If you want to share some other folder, make sure that the domain user has rights to that folder. In my case, I’ll have the domain user klimenta access the shared home folder for the domain user klimenta on the CentOS server. The permissions are already in place. Edit /etc/samba/smb.conf file and add these lines at the end.

[share]
        comment = klimenta domain user share
        path =  /home/MYDOMAIN/klimenta
        valid users = klimenta@kdomain.local
        guest ok = no
        writable = yes
        browsable = yes

Restart both services

systemctl restart smb.service
systemctl restart nmb.service

Now, from a Windows workstation go to \\ and you’ll see the folder opened with all the files in there.

This post is a slight modification of the official wiki for setting up Samba as an AD Domain Member. The wiki mentioned is a great article, but as described it doesn’t work on FreeBSD. There are two extra changes that you have to make and these changes are described below.

In my lab, I built a Windows 2012R2 domain controller/DNS and a FreeBSD 10.1 VM running Samba 4.4.5.
My Windows domain is kdomain.local and the NETBIOS name is MYDOMAIN. They are on the same subnet and the IP of the BSD VM is in the DNS. Let’s verify the prerequisites before we install Samba. Make sure that everything checks out.

This is the full name of my BSD VM.

hostname
freebsd03.kdomain.local

This is what I have in resolv.conf. 192.168.1.19 is the IP of the Windows box.

cat /etc/resolv.conf
search kdomain.local
nameserver 192.168.1.19

This is the hostname and the IP of my BSD box.

cat /etc/rc.conf
hostname="freebsd03.kdomain.local"
ifconfig_em0="inet 192.168.1.18 netmask 255.255.255.0"

Make sure it resolves properly in DNS.

host -t A freebsd03.kdomain.local
freebsd03.kdomain.local has address 192.168.1.18

Check the date/time on both systems. They have to be the same. If the time is not the same, it’s fine, but they have to be in different time zones.

date
Fri Aug 26 19:26:24 EDT 2016

Another check using getent in case you have something in /etc/hosts.

getent hosts freebsd03
192.168.1.18      freebsd03.kdomain.local

If everything checks out, you can install samba.

pkg install samba44

This is where Samba expects the config file which doesn’t exist by default.

smbd -b | grep CONFIGFILE
   CONFIGFILE: /usr/local/etc/smb4.conf

The log dir is automatically created under /var/log/samba4. If you need to change the log dir or any other input parameters, look at /usr/local/etc/rc.d/samba_server file, but don’t change this file. Use the parameters there to change them in /etc/rc.conf.

Before you go further, you need to know what’s realm, NETBIOS and workgroup in Samba terms. They are kind of misleading as you can see below from the samba config file. On the domain controller, open up a command prompt and type:

set | find  "DOMAIN"
USERDNSDOMAIN=KDOMAIN.LOCAL
USERDOMAIN=MYDOMAIN
USERDOMAIN_ROAMINGPROFILE=MYDOMAIN

My domain is KDOMAIN.LOCAL and the NETBIOS domain name is MYDOMAIN. The hostname of my domain controller is DC03, but that’s irrelevant.
Now create the Samba config file which is /usr/local/etc/smb4.conf.

[global]
        netbios name = freebsd03
        realm = KDOMAIN.LOCAL
        workgroup = MYDOMAIN
        security = ADS
        winbind enum groups = Yes
        winbind enum users = Yes
        winbind nss info = rfc2307
        idmap config *:range = 2000-9999
        idmap config * : backend = tdb

As you can see the netbios name is not the netbios name of your domain controller, it’s the hostname of your BSD box. The realm is the domain name and the workgroup is the NETBIOS name of the domain controller. Yep, it is misleading, but it is what it is.

Previously, I mentioned that there are two changes that you have to make that are different than the original wiki. So, this is the first change. In the original wiki article, they suggest picking up one of the three idmap modules.

   # Just adding the following three lines is not enough!!
       #  - idmap config ad
       #  - idmap config rid
       #  - idmap_config_autorid

If you go ahead and implement any of them, you won’t be able to enumerate the domain users with getent. More info here. So, skip that and just do the config file as described above.

Now that you have your config in place, check for any errors. Just do testparm.

testparm
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER

Press enter to see a dump of your service definitions

# Global parameters
[global]
        realm = KDOMAIN.LOCAL
        workgroup = MYDOMAIN
        security = ADS
        winbind enum groups = Yes
        winbind enum users = Yes
        winbind nss info = rfc2307
        idmap config *:range = 2000-9999
        idmap config * : backend = tdb

If everything is syntax OK, you can now join the BSD box to the domain.

net ads join -U administrator
Enter administrator's password:
Using short domain name -- MYDOMAIN
Joined 'FREEBSD03' to dns domain 'kdomain.local'

If you go back to your domain controller and open the ADUC (Active Directory Users and Computers), you’ll see your BSD hostname there.

Add these two lines to /etc/rc.conf.

samba_server_enable="YES"
winbindd_enable="YES"

Now, you can start Samba with service samba_server start. It also starts winbind daemon.

service samba_server start
Performing sanity check on Samba configuration: OK
Starting nmbd.
Starting smbd.
Starting winbindd.

Do all the checks.

wbinfo -u
MYDOMAIN\administrator
MYDOMAIN\guest
MYDOMAIN\klimenta
MYDOMAIN\krbtgt

wbinfo -g
MYDOMAIN\winrmremotewmiusers__
MYDOMAIN\domain computers
...

Now, do getent passwd. You won’t receive any domain users.
This is the second change that doesn’t apply from the official wiki. You’ll have to modify /etc/nsswitch.conf, so it looks like this. You have to replace compat with files for group and passwd entries.

group: files winbind
group_compat: nis
hosts: files dns
networks: files
passwd: files winbind
passwd_compat: nis

Reboot, and do getent passwd and getent group at this point. If you get the domain users and group, you are all set.

If you use pf, make sure that these ports are opened.

At this point, you’ll have the OS fully configured as a domain member, but you still can’t log in to FreeBSD with a domain account. In order to do that, we’ll have to make some changes.

Make sure you have these lines in smb.conf, restart samba service if necessary.

template shell = /bin/sh
template homedir = /home/%D/%U

The template shell and homedir means that each domain user will use /bin/sh for a shell and each home directory is expected to be under /home/ + domain name + the user name, in my case /home/MYDOMAIN/klimenta. Next, we should create a home dir for one of the users. In my case:

mkdir -p /home/MYDOMAIN/klimenta
cd /home/MYDOMAIN
chown -R klimenta@kdomain.local klimenta

Finally, the following three files needs to be modified: /etc/pam.d/sshd, /etc/pam.d/system and /etc/ssh/sshd_config. Reboot after the modifications.

In /etc/ssh/sshd_config, make sure these two lines are uncommented and set to yes and no.

PasswordAuthentication yes
ChallengeResponseAuthentication no

In /etc/pam.d/sshd, make sure you add this line three times so it looks like this. The order is also important.

# auth
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
auth            sufficient      /usr/local/lib/pam_winbind.so
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            required        pam_unix.so             no_warn try_first_pass

# account
account         sufficient      /usr/local/lib/pam_winbind.so
account         required        pam_nologin.so
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so              want_agent
session         required        pam_permit.so

# password
password        sufficient      /usr/local/lib/pam_winbind.so
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_unix.so             no_warn try_first_pass

In /etc/pam.d/system, make sure you add this line three times so it looks like this. The order is also important.

# auth
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
auth            sufficient      /usr/local/lib/pam_winbind.so
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            required        pam_unix.so             no_warn try_first_pass nullok

# account
account         sufficient      /usr/local/lib/pam_winbind.so
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so              want_agent
session         required        pam_lastlog.so          no_fail

# password
password        sufficient      /usr/local/lib/pam_winbind.so
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_unix.so             no_warn try_first_pass

At this point, after the reboot of course, you can log as a domain member.
What if we want to share our home directory or some other directory on the FreeBSD server? We have to add a config change in smb.conf file. I’ll explain how to share the home directory. If you want to share some other directory, make sure that the domain user has rights to that directory. In my case, I’ll have the domain user klimenta access the shared home directory for the domain user klimenta on the FreeBSD server. The permissions are already in place. Edit /usr/local/etc/smb4.conf file and add these lines at the end.

[share]
        comment = klimenta domain user share
        path =  /home/MYDOMAIN/klimenta
        valid users = klimenta@kdomain.local
        guest ok = no
        writable = yes
        browsable = yes

Restart samba service.

service samba_server start

Now, from a Windows workstation go to \\freebsd03 and you’ll see the directory.