openbmc ldap设定和验证，能从以下几个方向来看
- nss-pam-ldapd
[OpenBMC] LDAP 设定(一) - nss-pam-ldapd - LDAP server 架设
- Redfish/Web设定
[OpenBMC] LDAP 设定(二) - openldap 伺服架设与BMC的设定 - LDAP over TLS
终于到了最后一个部分 LDAPS, 这部分我们会依序介绍
- TLS的原理(这边会补充密码学基础)
- 非对称式加密 vs 对称式加密
- 数位签章
- 数位凭证
- TLS 握手(hankshake)
- 如何产生凭证
- 上传凭证到LDAP Server
- 上传凭证到BMC
- 有可能会遇到的问题 (补充我遇到的问题)
TLS的原理
对称式加密 vs 非对称式加密
密码学中会根据加密和解密的金钥是否相同，将加密法分为非对称是加密和对称是加密，非对称就是指加解密的金钥不相同，对称式就是加解密金钥是同一把
对称式加密
加解密金钥同一把，我们这边可以举个例子，例如底下Alice 和 Bob都有同一把金钥 (key = 2)，他们有一个已知的加密演算法，将文字转乘ASCII 再乘上Key 就是密文(ciper text)，所以解密演算法就是将密文(ciper text)除上key 再转成文字就能的到原文了
比较有名的演算法就是DES，应用的话就像TLS 中，双方会透过某些方式产生一组彼此都知道的Session Key，之后所有讯息都会透过这把Session Key 来做加解密
非对称式加密
非对称式加密中会有两把金钥，分别是私钥(private key)和公钥(public key)，如以下的RSA范例(select p=3, q=11)，Alice 先产生一组金钥，她会将其中的公钥先给了Bob，Bob用手上的公钥来加密一段讯息给Alice，这段讯息只有Alice手上的私钥能解开
上面的范例应该能体会非对称是加密的神奇之处，先说缺点就是"加解密速度比对称式慢很多"，但它的神奇之处衍伸出两个很著名的应用
- Key distribution (金钥分发)
- Digital Signature (数位签章)
后来因为数位签章有中间人攻击的风险，Digital Certificate (数位凭证)就此诞生
Key distribution (金钥分发)
前面我们有提到TLS最后目的是透过某个方法来产生一组session key，来对之后传输的讯息做加密，这边的"方法"就是指"金钥分发"，如以下范例
- Bob先产生一组Session Key, 用Alice给的公钥加密
- Alice收到之后，用私钥解密得到session key
- 之后双方讯息都是session key做加密
Digital Signature (数位签章)
网路上的讯息要怎么证明传送者是谁呢?数位签章就有点像是个人签名，签署这份讯息是由你送出来的，如以下范例，如果Alice 在讯息后面加上它的数位签章，这样Bob就可以分辨哪个是由Alice传送过来的
底下是数位签章制作方法和原理
- Alice 先将要传送的讯息M经过杂凑函数H产生H(M)
- 将H(M) 用私要加密，产生数位签章PA(H(M))
- 将数位签章PA(H(M))加到要传送的讯息M后面 (数位签章的长度是固定的)
- Bob收到讯息后，将数位签章PA(H(M))和讯息M'分开
- 将讯息M'经过杂凑函数H产生H(M')
- 将数位签章PA(H(M))用公钥解密，取得H(M)
- 比对H(M)和H(M') 是否相等，如果相等，表示讯息没有被窜改，而且是Alice传送过来的
简化一下沟通流程，大概就是以下这样
但这样其实会有中间人攻击(Man-in-the-middle attack)的风险，就是Bob怎么能确定一开始拿到Alice的公钥是真的呢?
Digital Certificate (数位凭证)
为了解决这个问题，就出现了certificate authority (CA)，一个来颁发凭证来证明你手上拿到的公钥是没问题的单位，这边继续用alice和bob来举例
- Alice 将她的个人基本讯息(CSR)和它的公钥拿给CA去签署(signed)
- CA颁发凭证(Certificate)给Alice
- 将Alice的讯息和公钥拿去做杂凑
- 用CA自己的私钥加密做成数位签章
- 然后加在Alice提供的讯息后面
- Alice将凭证传送给Bob
- Bob将凭证中的创建者(Issuer) xxCA解析出来，拿xxCA的公钥来看是否为这个真的是由其颁发，且凭证无损毁
TLS 握手(hankshake)
因为这篇文章是为了OpenBMC写的，所以这边我画了一张BMC在做LDAPS的时候hankshake的模拟图，
- Client送hellp给Server端，有些会传送自己的凭证(这个看情况)
- Server端收到Hello后，回传它的凭证
- 验证server 凭证是否合法，产生session key，连同之后这把key要搭配的对称加密演算法一起传给server
补充，在某些session key产生的演算法中，会用到Server的公钥(public key) 和client的私钥(private key)，所以这就是BMC要上传的LDAP凭证中，必须要包含private key的原因 - 确认Server那边讯息无误之后，所有讯息都会透过session key做加解密
如何产生凭证
这个部份OpenBMC已经有教学文件 ，How to configure the server TLS certificates for authentication
文章中有提到产生CSR，这部分可以透过OpenBMC的Create CSR功能来做，我这边是透过webUI，也可以透过Redfish，结果都一样的
分別做好signingReqClient.csr(LDAP), signingReqServer.csr(HTTPS)，就按照文章(How to configure the server TLS certificates for authentication
)的步骤继续完成：
openssl x509 -req -extensions my_ext_section -extfile myext-server.cnf -days 365 -in signingReqServer.csr -CA CA-cert.pem -CAkey CA-key.pem -CAcreateserial -out server-cert.pem但有几个地方需要注意，server certificate 的 cn 要填LDAPS server 的 hostname或IP，不知道LDAP server的hostname可以下已下指令
$ hostname
IRIS001client certificate 的 cn 这边填Ldap 的 admin user
上传凭证到LDAP Server
产生一个设定档certinfo.ldif，填入刚刚产生的cert放置路徑
$ cat certinfo.ldif
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap_slapd_key.pem将cn=config设定导入
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif最后，设定sldap 的参数
vi /etc/default/slapd
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"上传凭证到BMC並啟用
上传凭证
这可以透过web 或是 redfish，如果透过redfish 就是下以下指令，因为我原本就有certificate，就用replace 而已
CA certificate 上传 CA-cert.pem
[POST] /redfish/v1/CertificateService/Actions/CertificateService.ReplaceCertificate
{
"CertificateString": "-----BEGIN CERTIFICATE-----\nMIIDnTCCAoWgAwIBAgIUEZOkf69SVwaLa9l6Tp/gQMJioD4wDQYJKoZIhvcNAQEL\nBQAwXjELMAkGA1UEBhMCVFcxDzANBgNVBAgMBlRhaXdhbjEPMA0GA1UEBwwGVGFp\ncGVpMQ4wDAYDVQQKDAVqYWJpbDEMMAoGA1UECwwDYm1jMQ8wDQYDVQQDDAZUZXN0\nQ0EwHhcNMjExMDIxMDI1NzA4WhcNMjQwNzE3MDI1NzA4WjBeMQswCQYDVQQGEwJU\nVzEPMA0GA1UECAwGVGFpd2FuMQ8wDQYDVQQHDAZUYWlwZWkxDjAMBgNVBAoMBWph\nYmlsMQwwCgYDVQQLDANibWMxDzANBgNVBAMMBlRlc3RDQTCCASIwDQYJKoZIhvcN\nAQEBBQADggEPADCCAQoCggEBAKK1H9nIzIPHRRfVKPTmr1uwP8c23f/Oi+t1GVP3\nKijL/9KKDGwVf93F7wd1UWoEwWF5Hdfk84IYYe6skA5rh9RMWdQPcE9SVyDWkFTt\n/aMP/Ngl6l3zaqniW9uawa1ywXrEOdwRRpZwaizCVS0OxWaZn7mW9/aloqqTqf2q\nb4KX04x2Rdrnw3FWCnEpGaiaDc76bdeba0yg0/Lq1SFeYYuOYTcTIWOKB9BJyGhw\nD5G++QmwBUNK5s/ENzJZxnywX9yfYaARUURr19fo3pTCNMzBWOewt+PykCLTw0Wt\nmRvWpFwaIUgLaClrKkXh+9GcuEJUIRItpu06n/2nYtMAlhcCAwEAAaNTMFEwHQYD\nVR0OBBYEFPdM+K8hgEdU8/4rrFD5cjAjEgGDMB8GA1UdIwQYMBaAFPdM+K8hgEdU\n8/4rrFD5cjAjEgGDMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB\nAExEwJ1JD98pu5TW0aMi0L6mBMIayBaq68K9cJhB1xfA33buQIk54cOK7FXd9sBp\n+KY39vHNuYMp+J9tg/mqxS3d3/v5IcOvg96hRcHcPczWUmanNJuX29GZSoVkjMTF\n564EIfC6r0u9jbavlJsU5RuL7WSOgolvLa42PM44ShqfNIaKAi6hQzIVShhcG1UM\nulW1Ai6+Ih7yKeLVtkVTaDgSXODCTAPnXZI5qxWVWu/BU2CkllahdZ2Pna6mlvPv\n42po4X2MlBAGvy0ShwTxWA3QYqj1A87HpNjSqYLIwLWTE8S1+csWwgLGTMXpve0k\ncRgNpwA/3NURwmCvGs8yUyg=\n-----END CERTIFICATE-----\n",
"CertificateType": "PEM",
"CertificateUri": {
"@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates/1"
}
}LDAPS certificate 上传 client-cert.pem 和 client-key.pem 的合并档案
(因为产生Session Key的运算过程中会用到private key，但private key并不会传送给ldap server)，合并方法我是直接复制贴上，你也可以 echo client-cert.pem client-key.pem > Ldap.pem
最后上传给BMC
[POST]/redfish/v1/CertificateService/Actions/CertificateService.ReplaceCertificate
{
"CertificateString": "-----BEGIN CERTIFICATE-----\nMIIDrTCCApWgAwIBAgIUPJjMDmZ/Kn44kdLol7NaAoDyFAYwDQYJKoZIhvcNAQEL\nBQAwXjELMAkGA1UEBhMCVFcxDzANBgNVBAgMBlRhaXdhbjEPMA0GA1UEBwwGVGFp\ncGVpMQ4wDAYDVQQKDAVqYWJpbDEMMAoGA1UECwwDYm1jMQ8wDQYDVQQDDAZUZXN0\nQ0EwHhcNMjExMDIxMDI1ODIwWhcNMjIxMDIxMDI1ODIwWjBdMQswCQYDVQQGEwJU\nVzEPMA0GA1UECAwGVGFpd2FuMQ8wDQYDVQQHDAZUYWlwZWkxDjAMBgNVBAoMBWph\nYmlsMQwwCgYDVQQLDANibWMxDjAMBgNVBAMMBWFkbWluMIIBIjANBgkqhkiG9w0B\nAQEFAAOCAQ8AMIIBCgKCAQEAhpU78FV7loXU7uwT2fgMqVNrVac6OA80SoOxwCWO\nOR8WL3Z7R51ZIBgDe2WcC1mQGNO8ymt0YvcZInWJGPKlrSSIxGTcgPh36ZUx8WZw\nDjC05LaOoyPa/av/snkmsWHKCWd4tXALltb7fs+agaNPThBE8gqI7L6QvBExQgZf\nRaBLPZ6lizyb+ovEYOzY/wPh4VCYSCz+41eOEHxSno6hN4X8h7dGJwYRTMAt+Dys\nrCBIpTvKSJvRkVhh8SgEr4EV+izSEelbCMJZg3uv2aeabxpWYK7x4L4r8OWfQi2P\ndW5SkAUFjg6/tf16ZaOFUY4Ro3NxA1D49nxJhkLP8aBU+wIDAQABo2QwYjALBgNV\nHQ8EBAMCA4gwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHwYDVR0jBBgwFoAU90z4ryGA\nR1Tz/iusUPlyMCMSAYMwHQYDVR0OBBYEFMlmWZNjqmmMNFfGJRXvEfxDCL5jMA0G\nCSqGSIb3DQEBCwUAA4IBAQCYBY3cY78GmOqTbKByGXBwar5Nb7O6xYeQb/f3fJAJ\nJYLI5jZnKWbixo4P6jl34+21WGxivT2GxFC4m9qdB8YBkbhvtk5dpMynoGmKrC9d\nn+OamBUuHC8yw6zrGywauD1XLnwy+eUULg51gOFvvM4XVqg44pRwzGwnzvGSmGDq\n2vAD5KWglcJ9d0nMLRlCW70bZbgG46ifRJvDxATp69HL2aS1tpwA2xJz1akkCzn8\nHzfZD02D1xIpAOTIf5pevZakhBsdZKiJeobkyoVCI1/L3mJX/4PFIyxbVr5AchO6\nQXmVeNx5LQ09afIVI/FlQcf4EWtza/E8DAl4vO31NuFA\n-----END CERTIFICATE-----\n-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCGlTvwVXuWhdTu\n7BPZ+AypU2tVpzo4DzRKg7HAJY45HxYvdntHnVkgGAN7ZZwLWZAY07zKa3Ri9xki\ndYkY8qWtJIjEZNyA+HfplTHxZnAOMLTkto6jI9r9q/+yeSaxYcoJZ3i1cAuW1vt+\nz5qBo09OEETyCojsvpC8ETFCBl9FoEs9nqWLPJv6i8Rg7Nj/A+HhUJhILP7jV44Q\nfFKejqE3hfyHt0YnBhFMwC34PKysIEilO8pIm9GRWGHxKASvgRX6LNIR6VsIwlmD\ne6/Zp5pvGlZgrvHgvivw5Z9CLY91blKQBQWODr+1/Xplo4VRjhGjc3EDUPj2fEmG\nQs/xoFT7AgMBAAECggEACYYwkMmdCesu15TU/D5Lkxc6tWm0ux0I6Ygzpd/0zS/r\nXTnNFFxtg+Qju4Po1erJ5k2a3jLsZ21lqAki6pL9cURwjIBcOQ7lkGcpn0rfojlz\nMFnQcwvbwe/Zgc6E70MbcoftaQNk1Ef+G1NjGCX5BSUJLS+TPqZnO+I/TcvvN/S7\ncL+jP+9mTZ+U4ZsuGtW7T3yw3JpgAZ2jdNt5VB4sXilk1246btl/7kYeJqYEeK/K\nsLYJ+t4JhjBIq1Wpeblj2YHLfpSKxCdooBFiO+Pks5misk4Q1Y7ikvgMAKfKbmnm\nyrm9MN4yZ9ALKQAIBjz5YDjmvK8lbLg2xpJmoe30MQKBgQC9L9efhFTX2VWdpE+D\ngvVty3a8ZxvasG4PN9HCFlRrD+wfhAkU7DIJM6tfZoWkCo9txirBB2NTTUwIT/i8\n6Jb9ctZMdfHx0520vwxHdo3AduqE/z/RUk7YE3OWcM6AcZ7OxbqW3vkkaN15z5nG\nTORpFiKDW1Kv1lOEyxZ3HLw+sQKBgQC2HLc7u88zvah94/RyZzBtVthwpIW+Ow+6\nL/bZNbMmKh8n+kwKLXJZUjQfoY8en664LAWxxsvuOHerPmcxkwlga64ipNTZrjRL\n2aBc2wN0whY+ytaOCW7wF7MCxkGvYfFQyv2nZ6JSBM3Mss0KNZZNNbL79ZlTAGC4\nBiQLWSZxawKBgDpcXN73mpivkcq8mk7Oglmpb2p1QFF5JaqKJKoD62zPj561Q3vx\n1Qmjp9UZMlbFbzOE80FyvwA+kxrpWKkl8xYia9tQcx+PkVHlsasF9nqN9JCskQpI\nosvjTD/3cqyK4FuXAZVzGVZTByeBlEVpCPkl++WbsWlO65rGb5q1AZkxAoGAWsS7\nS2mTn+1jAsRQvYjTKVxE6vgFtUhI0XtApQjP7zDFcK6fod7/BKglVLK43AGpGyDO\nAcrdMDIy60ZiNuJbpRRmqdvQP2NFq5ygAkgjU9m9LrT49bib881MKxDYAmtl1Ogo\nP302+Xxtex6Pdgw5iug9+rlyH12r120wH/viXlsCgYBtEPGxwQuI7TSHvRi1Z6W0\nKPlEDRFidOWHRlPoqfUegCLgwIHvo6Jo5wDKRtmfDpbZovdDMvuvOM4KID5IeQas\nZkdKqtq2Ik15Tr2HRSiriktZYgO49gVHrfN59xTT1n2XIqBSvXQF3EOJ+7kXutzx\nzAFxrjvZ/QcxoBvCv/AqlA==\n-----END PRIVATE KEY-----\n",
"CertificateType": "PEM",
"CertificateUri": {
"@odata.id": "/redfish/v1/AccountService/LDAP/Certificates/1"
}
}啟用
这边要注意的是LDAP的server URI 要填hostname: "ldaps://IRIS001" 或是 IP (要和CERT上面的CN一样)
Web 设定
透过Redfish 设定
[PATCH]/redfish/v1/AccountService
{
"LDAP": {
"ServiceEnabled": true,
"ServiceAddresses": [
"ldaps://IRIS001"
],
"Authentication": {
"Username": "cn=admin,dc=bmc,dc=com",
"Password": "admin"
},
"LDAPService": {
"SearchSettings": {
"BaseDistinguishedNames": [
"dc=bmc,dc=com"
],
"GroupsAttribute": "gidNumber",
"UsernameAttribute": "uid"
}
}
}
}BMC端设定完后，就能用LDAPS user 登入BMC了
有可能会遇到的问题 (补充我遇到的问题)
当你登入不进去的话，可以下journalctl 来查看error log，如果log太多，可以先清除 journalctl --vacuum-time=1seconds，再测试一次
certificate is not yet valid
Jan 01 01:28:15 iris-obmc nslcd[582]: [7b23c6] <passwd="iris"> failed to bind to LDAP server ldaps://10.142.24.34: Can't contact LDAP server: error:1416F086:lib(20):func(367):reason(134) (certificate is not yet valid)
有可能是BMC时间不对，可以发现现在BMC时间是Thu 1970-01-01 01:30:55 UTC
root@iris-obmc:~# timedatectl status
Local time: Thu 1970-01-01 01:30:55 UTC
Universal time: Thu 1970-01-01 01:30:55 UTC
RTC time: n/a
Time zone: UTC (UTC, +0000)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no但Server的certificate的Not Before: Oct 21 03:00:20 2021 GMT
$ openssl x509 -in server-cert.pem -text -noout
openssl req -in signingReqClieCertificate:
Data:
Version: 3 (0x2)
Serial Number:
17:31:0f:21:a7:e5:08:03:18:88:5d:6a:32:ac:1d:a8:6b:18:e0:b2
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = TW, ST = Taiwan, L = Taipei, O = iris, OU = bmc, CN = TestCA
Validity
Not Before: Oct 21 03:00:20 2021 GMT
Not After : Oct 21 03:00:20 2022 GMT
Subject: C = TW, ST = Taiwan, L = Taipei, O = iris, OU = bmc, CN = TRKBC01
Subject Public Key Info:
Public Key Algorithm: rsaEncryption把BMC时间调回正常的就能解决了
hostname does not match name in peer certificate / bad LDAP Server URI
Oct 21 11:31:09 iris-obmc nslcd[582]: [b141f2] <passwd="iris"> failed to bind to LDAP server ldaps://10.142.24.34: Can't contact LDAP server: TLS: hostname does not match name in peer certificate
或
Oct 21 11:31:55 iris-obmc phosphor-ldap-conf[487]: bad LDAP Server URI
Oct 21 11:31:55 iris-obmc phosphor-ldap-conf[487]: Invalid argument was given.
这个是因为BMC的DNS无法解析LDAP server的hostname, 可以将hostname(IRIS001 )手动加入 hostname mapping list
root@intel-obmc:/etc# cat hosts
127.0.0.1 localhost.localdomain localhost
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 intel-obmc
196.142.253.189 IRIS001
