JobScheduler JOCとのAD連携

# JOC認証について

OSSジョブ管理システムJobScheduler V.1.11から導入されたJOCコックピットでのログイン認証は、shiro.iniファイルの設定内容に応じて次のいずれかを行います。

・Shiro認証:
　shiro.iniファイルに格納されている情報を使用しログインします
・LDAP認証:
　LDAPサービスを使用してログインします
　（V.1.12.1よりShiro認証とLDAP認証は組み合わせて設定できます）
・データベース認証:
　データベースに格納されている情報を使用しログインします

今回はShiro認証とLDAP認証を使用してshiro.iniファイルに格納されているユーザ認証と、WindowsServerとのAD連携について記載します。
JobSchedulerのインストールは以下の記事をご確認ください。
https://qiita.com/satoruf/items/fd78523c68a7c2a0593e

# 環境
●Jobschedulerサーバ
・CentOS 7.4
・PostgreSQL 9.6.11
・java version "1.8.0_191"
・JobSchedulerMaster 1.12.9
・JOC Cockpit 1.12.9

●ADサーバ
・WindowsServer 2016
・ADで使用するポート=389
・OU=cmdbuild
・ドメイン=test.local
※ADサーバの基本設定、OU、ドメインは作成されているものとします。

# ADユーザの作成
ADサーバより、
スタートボタン ＞ Windows管理ツール ＞ Active Directoryユーザとコンピュータの順で移動し、
JobSchedulerとAD連携させるユーザを作成します。
OU=cmdbuild上でユーザを新規作成します。
テストとして、以下のユーザを追加します。
性：yamashita
ユーザログオン名：yamashita@test.local
ユーザは次回ログオン時にパスワード変更が必要のチェックを外す
![a.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66557/bcc1b38f-f04a-bc63-da28-9852971d05c8.jpeg)

# ADユーザの確認
JobSchedulerサーバより、作成したADユーザが検索できることを確認します。

```shell-session
# ldapsearch -x -D "yamashita@test.local" -w ＜パスワード＞ -h ＜ADサーバのIPアドレス＞ -b "ou=cmdbuild,dc=test,dc=local" "cn=yamashita"

# extended LDIF
#
# LDAPv3
# base <ou=cmdbuild,dc=test,dc=local> with scope subtree
# filter: name=yamashita
# requesting: ALL
#

# yamashita, cmdbuild, test.local
dn: CN=yamashita,OU=cmdbuild,DC=test,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: yamashita
sn: yamashita
distinguishedName: CN=yamashita,OU=cmdbuild,DC=test,DC=local
instanceType: 4
whenCreated: 20190815050345.0Z
whenChanged: 20190815051321.0Z
displayName: yamashita
uSNCreated: 26577
uSNChanged: 26585
name: yamashita
objectGUID:: 4YKDbLmLJ0O0g/95YWRCOg==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 132103195394210174
lastLogoff: 0
lastLogon: 132103196012336402
pwdLastSet: 132103190251542680
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAOFznilgRHcx/3YhnWgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: yamashita
sAMAccountType: 805306368
userPrincipalName: yamashita@test.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=test,DC=local
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 132103196012336402

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
```

上記コマンドの結果の以下の
distinguishedName: CN=yamashita,OU=cmdbuild,DC=test,DC=local
CN=yamashita
がJOCとのAD連携するユーザ名となります。

# JOCでのAD連携設定
JobSchedulerサーバより、
shiro.ini.activeをコピーし、shiro.iniを作成します。

```shell-session
# su - scheduler 
$ cd sos-berlin.com/joc/resources/joc
$ cp -p shiro.ini.active shiro.ini
```

作成したshiro.iniにてAD連携設定を行います。
※以下の設定例の
・LDAP認証→ローカル認証
・ローカル認証→LDAP認証
より認証の組み合わせを環境に合わせて設定します。

・LDAP認証→ローカル認証の順で認証設定
　以下の設定では最初にLDAP認証を行い、LDAP認証に失敗するとローカル認証を行います。

```shell-session
$ vim shiro.ini
##[main]プロパティの最後に以下を追記します
ldapRealm.userDnTemplate = {0}                                     #ADサーバの場合は{0} のみ指定する
##ldapRealm.userDnTemplateは、対象がMicrosoft Active Directory以外の場合は
##以下のように組織目、ドメイン名が必要となる
##ldapRealm.userDnTemplate = cn={0},ou=cmdbuild,dc=test,dc=local   #組織名、ドメイン名
ldapRealm.searchBase = ou=cmdbuild,dc=test,dc=local                #組織名、ドメイン名
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://＜ADサーバのIPアドレス＞:389   #ADサーバIPアドレス:ポート
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm, $iniRealm
##securityManager.realms = $ldapRealm, $iniRealm にすることでLDAP認証→ローカル認証の順で行う
##securityManager.realms = $ldapRealm　と設定するとAD認証のみを行い、ローカル認証は行えなくなる
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
```
・ローカル認証→LDAP認証の順で認証設定
　以下の設定では最初にローカル認証を行い、ローカル認証に失敗するとAD認証を行います。

```shell-session
$ vim shiro.ini
##[main]プロパティの最後に以下を追記します
ldapRealm.userDnTemplate = {0}                                     #ADサーバの場合は{0} のみ指定する
##ldapRealm.userDnTemplateは、対象がMicrosoft Active Directory以外の場合は
##以下のように組織目、ドメイン名が必要となる
##ldapRealm.userDnTemplate = cn={0},ou=cmdbuild,dc=test,dc=local   #組織名、ドメイン名
ldapRealm.searchBase = ou=cmdbuild,dc=test,dc=local                #組織名、ドメイン名
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://＜ADサーバのIPアドレス＞:389   #ADサーバIPアドレス:ポート
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms =  $iniRealm, $ldapRealm
##securityManager.realms = $iniRealm, $ldapRealm にすることでローカル認証→LDAP認証の順で行う
##securityManager.realms = $ldapRealm　と設定するとAD認証のみを行い、ローカル認証は行えなくなる
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
```

設定後JOCのサービスの再起動等は必要なく、次回JOCへのログイン時に設定が反映されます。


## JOCでのユーザ作成、ロール権限の付与
JOCでのLDAP認証はシンプルバインドとなり、ロールはJOCで設定する必要があります。

JOCのWebUI
http://＜JOCのIPアドレス＞:4446/joc
にrootでログインします。
※今回の認証はShiroとLDAP認証組み合わせて設定しているため、Shiroで設定している既存のroot等のユーザはそのまま使用できます。
ログイン後、ユーザ管理画面 ＞ ユーザ作成の順で移動し、ADユーザを追加、ロール権限の付与を行います。
※追加するADユーザはAD認証を行うため、ここでパスワードは設定せずにそのまま登録を選択します。

![a.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66557/1a37db1f-2548-15a1-3e65-42760ae2211d.jpeg)

また、AD連携の設定が正常に反映されていることを確認します。

```shell-session
# su - scheduler 
$ cd sos-berlin.com/joc/resources/joc
$ cat shiro.ini.active
  ※設定した内容が反映されていることを確認する
```

ユーザ作成後、rootをログアウトし、ADユーザでログインできることを確認します。
アカウント：yamashita
パスワード：ADで設定したユーザパスワード


# 備考
JOCでのAD連携のユーザはCNの値となります。
以下のユーザをAD認証させる場合はCNにスペースが入っているためJOCでのユーザ作成もスペースを入れ作成する必要があります。
性：yamashita
名：yoshitami
ユーザログオン名：yoshitami@test.local
ユーザは次回ログオン時にパスワード変更が必要のチェックを外す


![無題.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66557/c56837d2-79b0-20c7-c91f-967c0803f75d.jpeg)

```shell-session
# ldapsearch -x -D "yamashita@test.local" -w ＜パスワード＞ -h ＜ADサーバのIPアドレス＞ -b "ou=cmdbuild,dc=test,dc=local" "cn=yamashita yoshitami"

# extended LDIF
#
# LDAPv3
# base <ou=cmdbuild,dc=test,dc=local> with scope subtree
# filter: cn=yamashita yoshitami
# requesting: ALL
#

# yamashita yoshitami, cmdbuild, test.local
dn: CN=yamashita yoshitami,OU=cmdbuild,DC=test,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: yamashita yoshitami
sn: yamashita
givenName: yoshitami
distinguishedName: CN=yamashita yoshitami,OU=cmdbuild,DC=test,DC=local
## 以下略
```
上記コマンドの結果の以下の
distinguishedName: CN=yamashita yoshitami,OU=cmdbuild,DC=test,DC=local
CN=yamashita yoshitami
がJOCとのAD連携するユーザ名となります。

JOCでのユーザ作成もユーザ名を以下のようにし、ロール権限を付与します。
ユーザ：yamashita yoshitami
![無題.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/66557/3d8032ab-0321-0de1-95d6-04a1ac0a064b.jpeg)

ユーザ作成後、ログアウトし、ADユーザでログインできることを確認します。
アカウント：yamashita yoshitami
パスワード：ADで設定したユーザパスワード