如何解决LDAP配置问题
概述
当遇到LDAP身份验证问题时,我们需要查找由JFrog平台或JFrog Artifactory以及LDAP目录返回的相应响应。在本文中,我们将展示如何使用tcpdump捕获网络流量,然后利用WireShark UI的优势分析、过滤LDAP事务并排除故障。
tcpdump是一个命令行网络数据包分析器,它将帮助我们收集在日志中找不到的信息。tcpdump是大多数Linux发行版中的标准包,你可以在这里获得它:https://www.tcpdump.org/。
WireShark是一个开源的网络数据包分析器,带有用户界面,有助于故障排除和分析LDAP连接。有关该工具的更多信息和下载链接,请参见https://www.wireshark.org/。
本文示例使用的配置如下:
JFrog平台:10.132.0.88
LDAP服务器:10.132.0.2
LDAP端口:389
LDAP设置:
LDAP组设置:
LDAP树:
指令
1.运行tcpdump并开始从JFrog Platform / Artifactory服务器主机捕获网络流量。
我们将使用以下命令选项:
我→监听接口。如果未指定,tcpdump将在系统接口列表中查找编号最低且已配置的up接口。接口参数“any”可用于从所有接口捕获数据包。
- n→不要将地址(即主机地址、端口号等)转换为名称。
- w文件→将原始数据包写入文件,而不是解析并打印出来。
主机→
港口→
例子:$ tcpdump -i any -n -w /var/opt/jfrog/artifactory/log/ldap. logPcap主机10.166.0.2和端口389
2.当tcpdump运行时,执行以下LDAP事务之一:
尝试登录使用LDAP身份验证的JFrog平台/ Artifactory
从LDAP设置建立一个测试连接
尝试在“LDAP组设置”中导入LDAP组
3.
4.在Wireshark中打开tcpdump捕获文件(ldap.pcap)。
您现在可以利用Wireshark过滤流量,而浏览,例如。按LDAP/TCP协议过滤(显示过滤器).
LDAP连通性分析
现在我们可以分析tcpdump捕获文件(LDAP .pcap),以确定JFrog Platform / Artifactory是否能够连接到LDAP服务器。
1.当成功建立到LDAP服务器的TCP连接时,可以看到以下TCP序列(TCP 3-way握手)。如果您只看到SYN发送,而没有SYN、ACK返回,那么从JFrog平台/ Artifactory主机无法访问LDAP服务器。
1 10.132.0.88 10.166.0.2 TCP 76 43114→389 [SYN] Seq=0 Win=28400 Len=0 MSS=1420 SACK_PERM=1 TSval=3831820 TSecr=0 WS=128
2 10.166.0.2 10.132.0.88 TCP 76 389→43114 [SYN, ACK] Seq=0 ACK =1 Win=28160 Len=0 MSS=1420 SACK_PERM=1 TSval=958410 TSecr=3831820 WS=128
3 10.132.0.88 10.166.0.2 TCP 68 43114→389 [ACK] Seq=1 ACK =1 Win=28416 Len=0 TSval=3831852 TSecr=958410
2.在下面的示例中,我们可能会看到SYN请求正在被重传,而没有返回SYN、ACK。如果您看到这一点,请验证您的LDAP服务器是否已启动,您配置的LDAP URL是否有效,以及网络配置(代理、防火墙、路由器等)是否允许流量到达LDAP服务器。1 10.132.0.88 10.166.0.2 TCP 76 47692→389 [SYN] Seq=0 Win=28400 Len=0 MSS=1420 SACK_PERM=1 TSval=4991787 TSecr=0 WS=128
2 10.132.0.88 10.166.0.2 TCP 76 [TCP重传]47692→389 [SYN] Seq=0 Win=28400 Len=0 MSS=1420 SACK_PERM=1 TSval=4992788 TSecr=0 WS=128
3 10.132.0.88 10.166.0.2 TCP 76 [TCP重传]47692→389 [SYN] Seq=0 Win=28400 Len=0 MSS=1420 SACK_PERM=1 TSval=4994792 TSecr=0 WS=128
4 10.132.0.88 10.166.0.2 TCP 76 [TCP重传]47692→389 [SYN] Seq=0 Win=28400 Len=0 MSS=1420 SACK_PERM=1 TSval=4998800 TSecr=0 WS=128
LDAP用户查询
JFrog平台/ Artifactory执行搜索以查找用户并获得用户的DN。根据LDAP Settings中提供的配置构建搜索请求。
1.从下面的输出中,您可以看到LDAP User Search返回1个结果,因为该用户存在于Active Directory中。在包2中,我们看到用户DN。1 10.132.0.88 10.166.0.2 LDAP 134 searchRequest(16)“ou =用户,dc =测试,dc = com”wholeSubtree
2 10.166.0.2 10.132.0.88 LDAP 398 searchResEntry(16)“cn = Valeriy彼得罗夫,ou =用户,dc =测试,dc = com”
3 10.166.0.2 10.132.0.88 LDAP 82 searchResDone(16) success [1 result]
用户在WireShark中搜索“valeriyp”的请求(包1):
用户搜索响应(分组2):
2.下面的示例显示了与Active Directory中的任何用户都不匹配的搜索。
用户搜索请求“test”,在AD中找不到用户“test”,返回“0 results”:1 10.132.0.88 10.166.0.2 LDAP 130 searchRequest(7)“ou =用户,dc =测试,dc = com”wholeSubtree
2 10.166.0.2 10.132.0.88 LDAP 82 searchResDone(7) success [0 results]
请求(数据包1):
回应(第二组):
LDAP用户认证
1.下面的示例显示了来自LDAP服务的绑定请求和成功的绑定响应。1 10.132.0.88 10.166.0.2 LDAP 131绑定请求(1)cn= valery Petrov,ou=Users,dc=test,dc=com"很简单
2 10.166.0.2 10.132.0.88 LDAP 82 bindResponse(1) success .日志含义
在LDAP搜索中找到的用户DN将在bindRequest中发送。WireShark将密码屏蔽为“simple”。如果我们检查数据包,我们可以看到明文中的密码,即下面示例中的“password”。
2.下面的示例显示了bindResponse中的invalidCredentials错误。如果输入的密码无效,可能会发生这种情况。1 10.132.0.88 10.166.0.2 LDAP 129 bindRequest(1)cn= valery Petrov,ou=Users,dc=test,dc=com"很简单
2 10.166.0.2 10.132.0.88 LDAP 82 bindResponse(1) invalidCredentials .日志含义
Wireshark:
LDAP组搜索分析
1.在下面的示例中,我们看到在Active Directory中成功搜索组。注意,searchRequest查询LDAP服务器并应用LDAP组设置中定义的过滤器,从搜索基中定义的DN开始。1 0.000000 10.132.0.88 10.166.0.2 LDAP 351 searchRequest(22)“ou =组,dc =测试,dc = com”wholeSubtree
2 0.035339 10.166.0.2 10.132.0.88 LDAP 207 searchResEntry(22)“cn =开发商,ou =组,dc =测试,dc = com”
3 0.035377 10.166.0.2 10.132.0.88 LDAP 222 searchResEntry(22)“cn =用户,ou =组,dc =测试,dc = com”
4 0.035382 10.166.0.2 10.132.0.88 LDAP 197 searchResEntry(22)“cn =支持,ou =组,dc =测试,dc = com”
5 0.035385 10.166.0.2 10.132.0.88 LDAP 224 searchResEntry(22)“cn =管理员,ou =组,dc =测试,dc = com”
6 0.035389 10.166.0.2 10.132.0.88 LDAP 246 searchResEntry(22)日志含义“cn =服务,ou =嵌套,ou = appgroups, ou =组,dc =测试,dc = com”
12 0.035482 10.166.0.2 10.132.0.88 LDAP 119 searchResDone(22) success[5个结果]
2.下面的示例显示了当没有找到Group对象时,在Group搜索请求中出现LDAP错误noSuchObject,因此返回" 0 results "。如果遇到此类错误,请检查是否正确配置了搜索基和过滤器。1 0.000951 10.132.0.88 10.166.0.2 LDAP 360搜索请求(2)“ou = IncorrectGroups, dc =测试,dc = com”wholeSubtree
2 0.034433 10.166.0.2 10.132.0.88 LDAP 96 searchResDone(2) noSuchObject [0 results]
成功登录和组关联的示例
1.在本例中,用户“valeriyp”是组“support”的成员,登录JFrog平台。
Wireshark界面流程:
在这个例子中我们可以看到:
1.用户搜索请求成功,返回“valeriyp”用户DN1 0.000000 10.132.0.88 10.166.0.2 LDAP 134 searchRequest(13)“ou =用户,dc =测试,dc = com”wholeSubtree
2 0.035437 10.166.0.2 10.132.0.88 LDAP 398 searchResEntry(13)“cn = Valeriy彼得罗夫,ou =用户,dc =测试,dc = com”
2.成功的用户绑定请求cn = Valeriy彼得罗夫,ou =用户,dc =测试,dc = com和“简单”(掩码密码)。在Wireshark界面中,检查该数据包的原始数据,可以发现密码。
无。9 0.073018 10.132.0.88 10.166.0.2 LDAP 131 binrequest (1)cn= valery Petrov,ou=Users,dc=test,dc=com"很简单
11 0.105634 10.166.0.2 10.132.0.88 LDAP 82 bindResponse(1) success日志含义
3.组搜索成功
15 0.129357 10.132.0.88 10.166.0.2 LDAP 435 searchRequest(14)“ou =组,dc =测试,dc = com”wholeSubtree
19 0.162667 10.166.0.2 10.132.0.88 LDAP 224 searchResEntry(14)“cn =支持,ou =组,dc =测试,dc = com”
查找LDAP响应时间
LDAP部分将计算并显示LDAP响应时间。在所有searchResultReference和SearchResultEntry响应之后,LDAP服务器返回searchResultDone响应,其中包含成功的指示或已发生的任何错误的详细信息。在数据包详细信息窗口中,展开LDAP部分。在本节中,我们将找到包含LDAP服务器响应时间的字段。

过滤长LDAP响应时间
现在,当我们知道了如何检查LDAP响应时间后,我们可能希望基于该响应时间创建一个过滤器,并仅显示耗时超过或小于设定时间的LDAP响应。
这在针对Artifactory的身份验证变慢的情况下特别有用,我们想知道这是否是由于LDAP服务器造成的。
在本例中,我们使用下面的过滤器语法只显示耗时超过30毫秒的响应。ldap。时间>= 0.03
进一步阅读:
LDAP调试指南
//www.si-fil.com/knowledge-base/ldap-debugging-guide/
LDAP/AD组同步/映射是如何工作的?
//www.si-fil.com/knowledge-base/how-does-ldap-ad-group-sync-mapping-work/
