版本比较
标识
- 该行被添加。
- 该行被删除。
- 格式已经改变。
k eycloak 并不会自动创建一系列 SSL 证书相关的配置,都要自己手撸。
如果还没安装 keycloak,可以参考前一篇文章『Docker Compose安装Keycloak』
然后,群晖要先把AD配置好。
获得群晖AD对应的SSL证书
首先,要把群晖为AD所生产的自签名SSL证书下载回来,后面需要用。
位置:群晖DSM管理后台-控制面板-安全性-证书。如果不太确定是哪张证书,可以点击『设置』,找到『Synology Directory Server』对应的证书下拉。
在对应的证书上点击右键,选择『导出证书』
导出的证书解压后有两个文件,一个是证书本身 cert.pem,另外一个是证书的私钥 privkey.pem,我们需要用到的是 cert.pem
另外一个使用OpenSSL来获取证书的方法(方便不支持导出的LDAP服务器)
代码块 |
---|
openssl s_client -showcerts -verify 5 -connect <AD/LDAP服务器IP或者域名>:636 < /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/) {a++}; out="ad-cert-"a".pem"; print >out}' |
上面命令运行后,当前目录下会生成多个ad-cert-x.pem的证书文件,找到对应的证书即可。
为 keycloak 生成 Java 所需要用的 keystore 文件
这里有个大坑。虽然新版本的 Java 建议出于更高的安全性考虑,keystore 应该使用 PKCS12 格式,keytool 也是默认创建 PKCS12 格式的 keystore。但,keycloak 不认。
所以,我们还是需要创建 JKS 格式的 keystore 文件。
我们进入到放置 docker-compose.yml 的目录,创建一个存放证书的目录 certs,并且把前面群晖导出的 cert.pem 也拷贝进去,一会需要用来导入
代码块 |
---|
mkdir certs # 下面的cert.pem改为自己实际存放的路径 cp ~/archive/cert.pem certs # 创建keystore文件 keytool -genkeypair -storepass password -storetype JKS -keyalg RSA -keysize 2048 -validity 3650 -dname "CN=KeyCloak" -alias KeyCloak -ext "SAN:c=DNS:localhost,IP:127.0.0.1" -keystore certs/server.jks # 把群晖的证书导入keystore keytool -storepass password -noprompt -trustcacerts -alias nas.synology -import -file certs/cert.pem -keystore certs/server.jks |
如果系统提示没有keytool,那么安装一下
代码块 |
---|
apt install openjdk-11-jre-headless |
把 keystore 映射到 docker
正常情况下,docker-compose 的 up 和 down 会删掉镜像里面的内容重新创建,所以刚才创建的证书如果直接放入到容器里,会丢失。我们有两个方法解决这个问题,一个是自己通过 dockerfile创建 docke 镜像,另外一个是把文件夹映射到容器。我们就不整那么麻烦的事情了,直接映射文件夹是最方便的。
我们需要在 docker-compose.yml 里面增加下面两段
代码块 | ||
---|---|---|
| ||
volumes: - ./certs:/opt/keycloak/certs |
这样就把当前 certs 文件夹映射到容器的 /opt/keycloak/certs 了
为 KeyCloak 指定使用自己创建的 keystore 文件
同样,在 docker-compose.yml 里面,environment 段增加下面的内容
代码块 | ||
---|---|---|
| ||
KC_SPI_TRUSTSTORE_FILE_FILE: /opt/keycloak/certs/server.jks KC_SPI_TRUSTSTORE_FILE_PASSWORD: password KC_SPI_TRUSTSTORE_FILE_HOSTNAME_VERIFICATION_POLICY: ANY KC_HTTPS_TRUST_STORE_FILE: /opt/keycloak/certs/server.jks KC_HTTPS_TRUST_STORE_PASSWORD: password |
修改过的 docker-compose.yml,看起来大概是这样(注意缩进,注意缩进,注意缩进)
然后,我们重启一下容器,这样,KeyCloak应该就可以正确识别SSL证书了。
KeyCloak 中增加 User Federation
我们进入 KeyCloak 的管理后台,左侧导航点击『User federation』,选择添加一个 LDAP 的源。
接着就看图说话。基本上只要改前面的内容,后面的内容就保持默认好了。
关于DN的问题,可以参考文章『Gitlab整合群晖Synology Active Directory』
提供上面的一些字符串,方便复制修改
代码块 |
---|
CN=Administrator,CN=Users,DC=NAIZHAO,DC=COM CN=Administrator,CN=Users,DC=BRA,DC=DO |
保存完,我们就可以开始测试了。
测试用户数据是否正常
点击左侧导航 Clients,然后点击 account 右边的 URL,会进入到一个登陆页面(新开个浏览器,或者浏览器开个无痕窗口,不然当前浏览器有 cookie,默认就登录了)。点击页面右上角的『Sign in』,新页面里面输入 AD 里面的用户名和密码,正常的话就登录成功了。
然后我们回到管理页面,点击左侧的 Users,Search Users的输入框里面输入一个星号*,点击搜索,你会发现 AD 里面的用户都出来了
后面可以继续创建realm,创建openid client。
关于DN
很多朋友搞不清什么是DN。其实简单理解,DN和文件夹、DNS都很像,也有一定的关联。
比如有个用户叫Bra,组织架构是在集团Com,事业群Naizhao,研发部Dev的运维Ops下面,那么找到Bra,有几种方法:
- 文件夹(目录)方式:COM\NAIZHAO\DEV\OPS\BRA
- 域名方式:bra.ops.dev.naizhao.com
- Active Directory/LDAP的DN方式:CN=Bra,CN=Ops,CN=Dev,DC=NAIZHAO,DC=COM
关于从 Windows Active Directory 同步的其他一些补充
从Windows AD同步的时候,cn 属性值是用户的全名。Windows AD 用户全名默认是用户的姓+名的组合,所以并不一定是登陆的用户名,特别是姓名是中文的时候。所以,如果使用 Windows AD 作为用户数据源,我们需要把设置中『LDAP searching and updating』-『Username LDAP attribute』从 cn 改为 sAMAccountName,同时把『Mappers』-『username』-『LDAP Attribute』也从 cn 改为 sAMAccountName,保存即可。
目录 |
---|