内网安全之-kerberos协议

news2024/11/17 12:40:52

kerberos协议是由麻省理工学院提出的一种网络身份验证协议，提供了一种在开放的非安全网络中认证识别用户身份信息的方法。它旨在通过使用秘钥加密技术为客户端/服务端应用提供强身份验证，使用kerberos这个名字是因为需要三方的共同参与才能完成一次认证流程。目前主流使用的kerberos版本为2005年RFC4120标准定义的KerberosV5版本，Windows、Linux和Mac OS均支持Kerberos协议

Kerberos基础

在Kerberos协议中，主要有以下三个角色：

  • 访问服务的客户端：Kerberos客户端是代表需要访问资源的用户进行操作的应用程序，例如打开文件、查询数据库、打印文档。每个Kerberos客户端在访问资源前都会请求身份验证。
  • 提供服务的服务端。域内提供服务的服务端，服务端都有一个独一的SPN。
  • 提供认证服务的KDC（Key Distribution Center密钥分发中心）：KDC秘钥发行中心是一种网络服务，它向活动目录域内的用户和计算机提供会话票据和临时会话秘钥，其服务账户为krbtgt。KDC作为活动目录域服务ADDS的一部分运行在每个域控制器上。

krbtgt账户，该用户是在创建活动目录时系统自动创建的一个账号，其作用是KDC秘钥发行中心的服务账号，其密码是系统随机生成的，无法正常登录主机。
Kerberos是一种基于票据Ticket的认证方式。客户端想要访问服务端的某个服务，首先需要购买服务端认可的ST服务票据（Service Ticket）。客户端在访问服务之前需要先买好票，等待服务验票之后才能访问，但是这张票并不能直接购买，需要一张TGT认购权证（Ticket Granting Ticket）。也就是说，客户端在买票之前必须要先获得一张TGT认购权证。TGT认购权证和ST服务票据均是由KDC（秘钥分发中心）发放，因为KDC是运行在域控制器上的，所以说TGT认购权证和ST服务票据均是由域控发放。
Kerberos使用TCP/UDP 88端口进行认证，使用TCP/UDP 464端口进行密码重设
image.png
Kerberos中一些名词的简称及含义：

简称全拼
DCDomain Controller，域控
krbtgtKDC 密钥发行中心服务账户
KDCKey Distribution Center:密钥分发中心，由域控担任
ADActive Directory:活动目录，里面包含域内用户数据库
ASAuthentication Service:认证服务
TGTTicket Granting Ticket:TGT 认购权证，由 KDC 的 AS 认证服务发放
TGSTicket Granting Service:票据授予服务
STService Ticket:ST 服务票据，由 KDC 的 TGS 票据授予服务发放

Kerberos协议有两个基础认证模块：AS_REQ & AS_REP 和 TGS_REQ & TGS_REP，以及微软扩展的两个认证模块S4U和PAC。S4U是微软为了实现委派而扩展的模块，分为S4U2Self和S4U2Proxy。在Kerberos最初设计的流程里只说明了如何证明客户端的真实身份，但是并没有说明客户端是否有权限访问该服务，因为域中不同权限的用户能够访问的资源是不同的。因此微软为了解决权限这个问题，引入了PAC（Privilege Attribute Certificate，特权属性证书）的概念。

PAC特权属性证书

PAC（Privilege Attribute Certificate，特权属性证书），其中包含的是各种授权信息、附加凭据信息、配置文件和策略信息等。例如用户所属的用户组，用户所具有的权限等，微软在自己的产品中所实现的额Kerberos流程加入了PAC概念，因为在域中不同权限的用户能够访问的资源是不同的，因此微软设计PAC用来辨别用户身份和权限。
在一个正常的Kerberos认证流程中，KDC返回的TGT认购权证和ST服务票据中都是带有PAC的，这样做的好处就是在以后对资源的访问中，服务端再接收到客户请求的时候不再需要借助KDC的帮助提供完整的授权信息来完成对用户权限的判断，而只需要根据请求中的包含的PAC信息直接与本地的ACL相比较做出裁决。

1、PAC结构

  • PAC的顶部结构
typedef unsigned long ULONG; 
typedef unsigned short USHORT; 
typedef unsigned long64 ULONG64; 
typedef unsigned char UCHAR;

typedef struct _PACTYPE { 
  ULONG cBuffers;
  ULONG Version; 
  PAC_INFO_BUFFER Buffers[1];
} PACTYPE;
  • cBuffers：包含数组缓冲区中的条目数
  • Version：版本
  • Buffers：包含一个PAC_INFO_BUFFER结构的数组

image.png
PAC_INFO_BUFFER结构包含了关于PAC的每个部分信息，这部分是最重要的，结构如下：

**typedef struct **_PAC_INFO_BUFFER {
ULONG ulType;
ULONG cbBufferSize;
ULONG64 Offset;
} PAC_INFO_BUFFER;

  • ultype：包含此缓冲区中包含的数据的类型，可能是以下之一
    • Logon Info (1)
    • Client Info Type(10)
    • UPN DNS Info (12)
    • Sserver Cechksum (6)
    • Privsvr Cechksum (7)
  • cbBufferSize：缓冲大小
  • Offset：缓冲偏移量

2、PAC凭证信息

LOGON INFO类型的PAC_LOGON_INFO包含Kerberos票据客户端的凭据信息。数据本身包含在一个KERB_VALIDATION_INFO结构中，该结构是由NDR编码的。NDR编码的输出被放置在LOGON INFO类型的PAC_INFO_BUFFER结构中。如下：

**typedef struct **_KERB_VALIDATION_INFO {
FILETIME Reserved0;
FILETIME Reserved1;
FILETIME KickOffTime;
FILETIME Reserved2;
FILETIME Reserved3;
FILETIME Reserved4;
UNICODE_STRING Reserved5;
UNICODE_STRING Reserved6;
UNICODE_STRING Reserved7;
UNICODE_STRING Reserved8;
UNICODE_STRING Reserved9;
UNICODE_STRING Reserved10;
USHORT Reserved11;
USHORT Reserved12;
ULONG UserId;
ULONG PrimaryGroupId;
ULONG GroupCount;
[size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
ULONG UserFlags;
ULONG Reserved13[4];
UNICODE_STRING Reserved14;
UNICODE_STRING Reserved15;
PSID LogonDomainId;
ULONG Reserved16[2];
ULONG Reserved17;
ULONG Reserved18[7];
ULONG SidCount;
[size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
PSID ResourceGroupDomainSid;
ULONG ResourceGroupCount;
[size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
} KERB_VALIDATION_INFO;

重点字段：

  • Acct Name:该字段对应的值是用户 sAMAccountName 属性的值
  • Full Name:该字段对应的值是用户 displayName 属性的值
  • User RID:该字段对应的值是用户的 RID，也就是用户 SID 的最后部分
  • Group RID:对于该字段，域用户的 Group RID 恒为 513(也就是 Domain Users 的 RID)，机器用户的 Group RID 恒为 515(也就是 Domain Computers 的 RID)，域控的 Group RID 恒为 516(也就是 Domain Controllers 的 RID)
  • Num RIDS:用户所属组的个数
  • GroupIDS:用户所属的所有组的 RID

3、PAC签名

PAC中包含两个数字签名：PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM。PAC_SERVER_CHECKSUM是使用服务秘钥进行签名，而PAC_PRIVSVR_CHECKSUM是使用KDC秘钥进行签名。签名有两个原因。首先，存在带有服务秘钥的签名，以验证此PAC由服务进行了签名。其次，带有KDC秘钥的签名是为了防止不受信息的服务用无效的PAC为自己伪造票据。这两个签名分别以PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM类型的PAC_INFO_BUFFER发送，在PAC数据用于访问控制之前，必须检查PAC_SERVER_CHECKSUM签名，验证客户端是否知道服务的秘钥。而PAC_PRIVSVR_CHECKSUM签名验证是可选的，默认不开启，它用于验证PAC是否由KDC签发，而不是由KDC以外的具有访问服务密钥的人放入票据

4、KDC验证PAC

PAC中是有两个签名的：PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM。一个使用服务秘钥进行签名，另一个使用KDC秘钥进行签名。当服务端收到客户端发来的AP-REQ消息时，只能校验PAC_SERVER_CHECKSUM 签名，并不能校验PAC_PRIVSVR_CHECKSUM签名。因此，正常来说如果需要校验PAC_PRIVSVR_CHECKSUM签名的话，服务端还需要将客户端发来的ST服务票据中的PAC签名发给KDC校验。但是，大部分服务默认并没有开启KDC验证PAC，因此服务端就无需将ST服务票据中的PAC签名发给KDC校验了，这也是白银票据能攻击的前提，因为如果配置了需要验证PAC_PRIVSVR_CHECKSUM签名的话，服务端会将这个PAC数字签名以KRB_VERIFY_PAC的消息通过RPC协议发送给KDC，KDC再将验证这个PAC的数字签名结果以RPC返回码的形式发送给服务端，服务端就可以根据这个返回结果判断PAC的真实性和有效性了。因此如果服务主机配置了要校验PAC_PRIVSVR_CHECKSUM签名的话，就算攻击者拥有服务秘钥，可以制作ST服务票据，也不能伪造KDC的PAC_PRIVSVR_CHECKSUM签名，自然就无法通过KDC的签名校验了。

Kerberos认证流程

image.png

1、AS-REQ请求分析

AS-REQ：当域内某个用户想要访问域内某个服务时，于是输入用户名和密码，本机就会向KDC的AS认证服务发送一个AS-REQ认证请求，该请求包中包含如下信息：

  • 请求的用户名(cname)。
  • 域名(realm)。
  • Authenticator:一个抽象的概念，代表一个验证。这里是用户密钥加密的 时间戳。
  • 请求的服务名(sname):AS-REQ 这个阶段请求的服务都是 krbtgt。
  • 加密类型(etype)。
  • 以及一些其他信息:如版本号，消息类型，票据有效时间，是否包含 PAC，协商选项等。

2、AS-REP回复包

AS-REP：当KDC的AS认证服务接收到客户端发来的AS-REQ请求后，从活动目录数据库中取出该用户的秘钥，然后用该秘钥对请求包中的Authenticator预认证部分进行解密，如果解密成功，并且时间戳在有效的范围内，则证明请求者提供的用户秘钥正确。KDC的AS认证服务在成功认证客户端的身份之后，发送AS-REP响应包给客户端。AS-REP响应包中主要包含以下信息：

  • 请求的用户名(cname)
  • 域名(crealm)
  • TGT 认购权证:包含明文的版本号，域名，请求的服务名，以及加密部分 enc-part。加密部分用 krbtgt 密钥加密。加密部分包含 Logon Session Key、用户名、域名、认证时间、认证到期时间和 authorization-data。 authorization-data 中包含最重要的 PAC 特权属性证书(包含用户的 RID， 用户所在组的 RID) 等
  • enc_Logon Session Key:使用用户密钥加密 Logon Session Key 后的 值，其作用是用于确保客户端和 KDC 下阶段之间通信安全。也就是 AS- REP 中最外层的 enc-part
  • 以及一些其他信息:如版本号，消息类型等

3、TGS-REQ & TGS-REP

客户端在收到KDC的AS-REP回复后，使用用户秘钥解密enc_Logon Session Key(也就是最外层的 enc-part)，得到Logon Session Key，并且也拿到了TGT认购权证，之后它会在本地缓存此TGT认购权证和Logon Session Key。现在客户端需要凭借这张TGT认购权证向KDC购买相应的ST服务票据。ST服务票据是KDC另一个服务TGS票据授予服务发放的，在这个阶段，微软引入两个扩展子协议S4u2self 和 S4u2Proxy。

3.1 TGS-REQ请求

TGS-REQ：客户端拿着上一步获得的TGT认购权证发起TGS-REQ请求，向KDC购买指定服务的ST服务票据，请求主要包含如下信息。

  • 域名(realm)
  • 请求的服务名(sname)
  • TGT 认购权证
  • Authenticator:一个抽象的概念，代表一个验证。这里使用 Logon Session Key 加密的时间戳
  • 加密类型(etype)
  • 以及一些其他信息:如版本号，消息类型，协商选项，票据到期时间等

TGS-REP回复包

TGS-REP：KDC的TGS服务接收到TGS-REQ请求之后，首先使用krbtgt秘钥解密TGT认购权证中加密部分得到Logon Session Key和PAC等信息，如果能解密成功则说明该TGT认购权证是KDC颁发的，然后验证PAC的签名，如果签名正确，则证明PAC未经过篡改，然后使用Logon Session Key解密Authenticator得到的时间戳等信息，如果能够解密成功，并且票据时间在范围内，则验证了会话的安全性。在完成上述的检测后，KDC的TGS服务完成了对客户端的认证，TGS服务发送响应包给客户端，响应包主要包含如下信息：

  • 请求的用户名(cname)
  • 域名(crealm)
  • ST 服务票据:包含明文的版本号，域名，请求的服务名，以及加密部分 enc-part，加密部分用服务密钥加密。加密部分包含用户名、域名、认证 时间、认证到期时间、Service Session key 和 authorization-data。 authorization-data 中包含最重要的 PAC 特权属性证书(包含用户的 RID， 用户所在的组的 RDI) 等。
  • enc_Service Session key:使用 Logon Session key 加密的 Service Session key，其作用是用于确保客户端和 KDC 下阶段之间通信安全。
  • 以及一些其他信息:如版本号、消息类型等。

TGS-REP这步中KDC并不会验证客户端是否有权限访问服务端。因此，这一步不管用户有没有访问服务的权限，只要TGT正确，均会返回ST服务票据，这也就是kerberoasting能利用的原因，任何一个域内用户，都可以请求域内任何一个服务的ST服务票据。

1）ST服务票据

TGS-REP 响应包中的 ticket 便是 ST 服务票据了。ST 服务票据中包含明文显示的信息，如版本号 tkt-vno、域名 realm、请求的服务名 sname。但是 ST 服务票据中最重要的还是加密部分，加密部分是使用服务密钥加密的。加密部分主要包含 的内容有 Server Session Key、请求的用户名 cname、域名 crealm、认证时间 authtime、认证到期时间 endtime、authorization-data 等信息。最重要的还是 authorization-data 部分，这部分中包含客户端的身份权限等信息，这些信息包含在PAC中。

2）Service Session key

TGS-REP 响应包最外层的那部分便是 Service Session Key 了，其作用是用于 确保客户端和 KDC 下阶段之间通信安全，它使用 Logon Session Key 加密。
对其进行解密，它主要包含的内容是认证时间 authtime、认证到期时间 endtime、域名 srealm、请求的服务名 sname、协商标志 flags 等一些信息。 需要说明的是，在 ST 服务票据中也包含 Service Session Key。

双向认证（AP-REQ&AP-REP）

AP-REQ请求

AP-REQ：客户端接收到KDC的TGS回复后，通过缓存的Logon Session Key解密enc_Service Session key 得到Service Session Key，同时也拿到了 ST(Service Ticket)服务票据。Serivce Session Key 和 ST 服务票据会被客户端缓存。客户端访问指定服务时，将发起 AP-REQ 请求，该请求主要包含如下的内容:

  • ST 服务票据(ticket)
  • Authenticator:一个抽象的概念，代表一个验证。这里指 Serivce Session Key 加密的时间戳
  • 以及一些其他信息:如版本号、消息类型，协商选项等

AP-REP回复包

AP-REP:这一步是可选的，当客户端希望验证提供服务的服务端时(也就是 AP- REQ 请求中 mutual-required 协商选项为 True)，服务端返回 AP-REP 消息。服 务端收到客户端发来的 AP-REQ 消息后，通过服务密钥解密 ST 服务票据得到 Service Session Key 和 PAC 等信息，然后用 Service Session Key 解密 Authenticator 得到时间戳。如果能解密成功且时间戳在有效范围内，则验证了客户端的身份。验证了客户端身份后，服务端从 ST 服务票据中取出 PAC 中代表用户身份权限信息的数据，然后与请求的服务 ACL 做对比，生成相应的访问令牌。 同时，服务端会检查 AP-REQ 请求中 mutual-required 协商选项是否为 True，如果为 True 的话，说明客户端想验证服务端的身份。此时，服务端会用 Service Session Key 加密时间戳作为 Authenticator，在 AP-REP 响应包中发送给客户端 进行验证。如果 mutual-required 选项为 False 的话，服务端会根据访问令牌的权限决定是否返回相应的服务给客户端。AP-REP 响应包中主要包括如下信息:

  • 版本号
  • 消息类型
  • enc-part:使用 Serivce Session Key 加密的时间戳

Kerberos协议的安全问题

image.png
在 AS-REQ 请求阶段，是用用户密码 Hash 或 AES Key 加密的时间戳。因此当只获得了用户密码 Hash 时，也可以发起 AS-REQ 请求，所以也就造成了 PTH 哈希传递攻击;当只获得用户密码的 AES Key 时，也可以发起 AS-REQ 请求，所以也就造成了 PTK 密钥传递攻击。
而 AS-REQ 请求包中 cname 字段的值代表用户名，这个值存在和不存在，返回的包有差异，所以可以用于枚举域内用户名，这种攻击方式被称为 域内用户枚举攻击 (当未获取到有效域用户权限时，可以使用这个方法枚举域内用户)。并且当用户名存在，密码正确和密码错误时，返回的包也不一样，所以可以进行用户名密码爆破。但是在实战中，渗透测试人员通常都会使用一种被称为 密码喷洒 (Password Spraying)的攻击方式来进行测试和攻击。对密码进行喷洒式的攻击，这个叫法很形象，因为它属于自动化密码猜测的一种。这种针对所有用户的自动密码喷洒通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导 致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒是用固定的密码去跑所有的用户名。
在 AS-REP 阶段，由于返回的 TGT 认购权证是由 krbtgt 用户的密码 Hash 加密的，因此如果我们拥有 krbtgt 的密码 hash 就可以自己制作一个 TGT 认购权证，这种攻击方式被称为黄金票据攻击。同样，在 TGS-REP 阶段，TGS_REP 里面的 ST 服务票据是使用服务的 hash 进行加密的，如果我们拥有服务的 hash，就可以签发任意用户的 ST 服务票据，这个票据也被称为白银票据，这种攻击方式被称为白银票据攻击。相较于黄金票据，白银票据使用要访问服务的 hash，而不是 krbtgt 的 hash。
在 AS-REP 阶段，Login session key 是用用户密码 Hash 加密的。对于域用户，如果设置了“Do not require Kerberos preauthentication”不需要预认证选项，此时攻击者向域控制器的 88 端口发送 AS_REQ 请求，此时域控不会做任何验证就将 TGT 认购权证和该用户 Hash 加密的 Login Session Key 返回。因此，攻击者就可以对获取到的用户 Hash 加密的 Login Session Key 进行离线破解，如果破解成功，就能得到该用户的密码明文，这种攻击方式被称为 AS-REP Roasting 攻击。
在 TGS-REP 阶段，由于 ST 服务票据是用服务 Hash 加密的。因此，如果我们能获取到 ST 服务票据，就可以对该 ST 服务票据进行利息破解，得到服务的 Hash，这种攻击方式被称为 Kerberoasting 攻击。这个问题存在的另外一个因素 是因为用户向 KDC 发起 TGS_REQ 请求，不管用户对服务有没有访问权限，只要 TGT 认购权证正确，那么 KDC 都会返回 ST 服务票据。其实 AS_REQ 里面的服务就是 krbtgt，也就是说这个攻击方式同样可以用于爆破 AS_REP 里面的 TGT 认购 权证，但是之所以没见到这种攻击方式是因为 krbtgt 的密码是随机生成的，爆破不出来

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1571369.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

中科驭数DPU技术开放日秀“肌肉”：云原生网络、RDMA、安全加速、低延时网络等方案组团亮相

中科驭数DPU技术开放日秀“肌肉”：云原生网络、RDMA、安全加速、低延时网络等方案组团亮相

2024年3月29日，中科驭数以“DPU构建高性能云算力底座”为主题的线上技术开放日活动成功举办。在开放日上，中科驭数集中展现了其在低时延网络、云原生网络及智算中心网络三大关键场景下的技术成果与五大核心DPU解决方案，凸显了中科驭数在高性能…
阅读更多...
RDD算子（四）、血缘关系、持久化

RDD算子（四）、血缘关系、持久化

1. foreach 分布式遍历每一个元素，调用指定函数 val rdd sc.makeRDD(List(1, 2, 3, 4)) rdd.foreach(println) 结果是随机的，因为foreach是在每一个Executor端并发执行，所以顺序是不确定的。如果采集collect之后再调用foreach打印&#xf…
阅读更多...
使用CSS计数器，在目录名称前加上了序号，让目录看起来更加井然有序

使用CSS计数器，在目录名称前加上了序号，让目录看起来更加井然有序

目录（Text of Contents缩写为TOC），其实就是一篇文章的概要或简述。这好比，去书店买书，先是被这本书的标题所吸引，而后我们才会，翻开这本书目录，看看这本书主要是在讲些什么&#xff…
阅读更多...
Claude 3 on Amazon Bedrock 结合多智能体助力 Altrubook AI 定义消费者 AI 新范式

Claude 3 on Amazon Bedrock 结合多智能体助力 Altrubook AI 定义消费者 AI 新范式

关于 Altrubook AI 智能消费决策机器人 Altrubook 是全球首创场景化智能决策机器人，由国内外大厂等前员工共同研发，具有定制化 IP 决策机器人、沉浸式购物体验和需求匹配优化等独特优势。目前，Altrubook AI 已完成与 Claude 3 on Amazon Bedr…
阅读更多...
【深度优先】【树上倍增 】2846. 边权重均等查询

【深度优先】【树上倍增 】2846. 边权重均等查询

本文涉及知识点 深度优先 树上倍增 LeetCode2846. 边权重均等查询 现有一棵由 n 个节点组成的无向树，节点按从 0 到 n - 1 编号。给你一个整数 n 和一个长度为 n - 1 的二维整数数组 edges ，其中 edges[i] [ui, vi, wi] 表示树中存在一条位于节点 ui…
阅读更多...
备战蓝桥杯---贡献法刷题

备战蓝桥杯---贡献法刷题

话不多说，直接看题： 什么是贡献法？这是一种数学思想，就是看每一个元素对总和的贡献。 1. 我们可以先枚举区间再统计次数，但这显然TLE。我们可以发现，每一个孤独的区间对应一个孤独的牛，因此我…
阅读更多...
注意力机制篇 | YOLOv8改进之添加多尺度全局注意力机制DilateFormer（MSDA）| 即插即用

注意力机制篇 | YOLOv8改进之添加多尺度全局注意力机制DilateFormer（MSDA）| 即插即用

前言：Hello大家好，我是小哥谈。多尺度全局注意力机制DilateFormer是一种用图像识别任务的深度学习模型。它是在Transformer模型的基础上进行改进的，旨在提高模型对图像中不同尺度信息的感知能力。DilateFormer引入了多尺度卷积和全局注意力机制来实现多尺度感知。具体来说，…
阅读更多...
考古：IT架构演进之IOE架构

考古：IT架构演进之IOE架构

考古：IT架构演进之IOE架构 IOE架构（IBM, Oracle, EMC）出现在20世纪末至21世纪初，是一种典型的集中式架构体系。在这个阶段，企业的关键业务系统往往依赖于IBM的小型机（后来还包括大型机）、Oracle…
阅读更多...
题库管理系统-基于Springboot实现JAVA+SQL离散数学题库管理系统(完整源码+LW+翻译)

题库管理系统-基于Springboot实现JAVA+SQL离散数学题库管理系统(完整源码+LW+翻译)

基于Springboot实现JAVASQL离散数学题库管理系统(完整源码LW翻译) 概述： 本系统具体完成的功能如下： 1题库的管理与维护：新题的录入，修改，删除等功能。 2生成试卷：包括自动生成与手工改动，要…
阅读更多...
ThingsBoaed、系统模块层级讲解

ThingsBoaed、系统模块层级讲解

系统管理员能够使用租户配置文件为多个租户配置通用设置。每个租户在单个时间点都拥有唯一的个人资料。 让我们一一查看租户配置文件中的可用设置。 配置文件配置 这些设置允许系统管理员配置对租户创建的实体数量的限制，设置每月最大消息数、API 调用数的限制&…
阅读更多...
Vue - 1（ 13000 字 Vue 入门级教程）

Vue - 1（ 13000 字 Vue 入门级教程）

一：Vue 1.1 什么是 Vue Vue.js（通常称为Vue）是一款流行的开源JavaScript框架，用于构建用户界面。Vue由尤雨溪在2014年开发，是一个轻量级、灵活的框架，被广泛应用于构建单页面应用（SPA&#xf…
阅读更多...
java自动化测试学习-03-06java基础之运算符

java自动化测试学习-03-06java基础之运算符

运算符 算术运算符 运算符含义举例加法，运算符两侧的值相加ab等于10-减法，运算符左侧减右侧的值a-b等于6*乘法，运算符左侧的值乘以右侧的值a*b等于16/除法，运算符左侧的值除以右侧的值a/b等于4%取余，运算符左侧的值除…
阅读更多...
matlab使用教程(34)—求解时滞微分方程(2)

matlab使用教程(34)—求解时滞微分方程(2)

1.具有状态依赖时滞的 DDE 以下示例说明如何使用 ddesd 对具有状态依赖时滞的 DDE（时滞微分方程）方程组求解。Enright 和Hayashi [1] 将此 DDE 方程组用作测试问题。方程组为： 方程中的时滞仅出现在 y 项中。时滞仅取决于第二个分量 y 2 t …
阅读更多...
每日面经分享（Git经典题目，Git入门）

每日面经分享（Git经典题目，Git入门）

1. GitHub是什么 a. Git是一个分布式版本控制系统，作用是跟踪、管理和协调软件开发项目中的代码更改。 b. 提供了一种有效的方式来管理代码的版本历史，以及多人协作开发的能力。 2. Git的作用有哪些 a. 版本控制：Git可以记录每次代码更改的…
阅读更多...
政安晨：【Keras机器学习实践要点】（十六）—— 图像分类从零开始

政安晨：【Keras机器学习实践要点】（十六）—— 图像分类从零开始

目录 简介 设置 加载数据：猫与狗数据集 原始数据下载 滤除损坏的图像 生成数据集 将数据可视化 使用图像数据增强 数据标准化 预处理数据的两个选项 配置数据集以提高性能 建立模型 训练模型 对新数据进行推理 政安晨的个人主页：政安晨 欢…
阅读更多...
【快捷部署】011_PostgreSQL（16）

【快捷部署】011_PostgreSQL（16）

📣【快捷部署系列】011期信息 编号选型版本操作系统部署形式部署模式复检时间011PostgreSQL16Ubuntu 20.04Docker单机2024-03-28 一、快捷部署 #!/bin/bash ################################################################################# # 作者&#xff1…
阅读更多...
【二分查找】Leetcode 二分查找

【二分查找】Leetcode 二分查找

题目解析 二分查找在数组有序可以使用，也可以在数组无序的时候使用（只要数组中的一些规律适用于二分即可） 704. 二分查找 算法讲解 当left > right的时候，我们循环结束，但是当left和right缩成一个点的时候&#x…
阅读更多...
DDR3接口

DDR3接口

mig IP核的配置 首先添加mig IP核   然后确认以下工程信息，主要是芯片型号以及编译环境，没什么问题后点击next.   如下图所示，这一页选择"Create Design"，在"Component Name"一栏设置该IP元件的名称&…
阅读更多...
Redis数据库——群集（主从、哨兵）

Redis数据库——群集（主从、哨兵）

目录 前言 一、主从复制 1.基本原理 2.作用 3.流程 4.搭建主动复制 4.1环境准备 4.2修改主服务器配置 4.3从服务器配置（Slave1和Slave2） 4.4查看主从复制信息 4.5验证主从复制 二、哨兵模式——Sentinel 1.定义 2.原理 3.作用 4.组成 5.…
阅读更多...
59 使用 uqrcodejs 生成二维码

59 使用 uqrcodejs 生成二维码

前言 这是一个最近的一个来自于朋友的需求, 然后做了一个 基于 uqrcodejs 来生成 二维码的一个 demo package.json 中增加以依赖 "uqrcodejs": "^4.0.7", 测试用例 <template><div class"hello"><canvas id"qrcode&qu…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023