问题似乎是非特权AD用户帐户无法访问安全描述符的SACL.要解决此问题并仍然检索ntSecurityDescriptor(减去SACL)，请向控件发送设置了所有其他标志的值(该值为7):

The issue appears to be that non-privileged AD user accounts will not have access to the SACL of the security descriptor. To get around this and still retrieve the ntSecurityDescriptor (minus the SACL), send the control with a value of all other flags set (which would be a value of 7):

// OWNER_SECURITY_INFORMATION + GROUP_SECURITY_INFORMATION + DACL_SECURITY_INFORMATION
$sdFlags = 7;

$ctrl1 = array(
    "oid" => "1.2.840.113556.1.4.801",
    "iscritical" => true,
    "value" => sprintf("%c%c%c%c%c", 48, 3, 2, 1, $sdFlags)
);
if (!ldap_set_option($ldap, LDAP_OPT_SERVER_CONTROLS, array($ctrl1))) {
    echo "Failed to set server controls";
}

我的猜测是MS文档没有错，LDAP_SERVER_SD_FLAGS_OID的默认值是要设置的 all 标志(包括SACL).由于大多数普通帐户无法访问该SACL，因此AD可能决定不返回安全描述符的任何部分，因此即使您选择了查询，也不会返回ntSecurityDescriptor值.

My guess is that the MS docs are not wrong, the default value of the LDAP_SERVER_SD_FLAGS_OID is for all flags to be set (which includes the SACL). Since most normal accounts do not have access to that SACL, AD probably decides to return no portion of the security descriptor, and thus no ntSecurityDescriptor value is returned from a query even though you select it.

另一个重要说明，如果您正在使用LDAP分页，则似乎会干扰此控件.您不能同时使用分页和此控件.我不确定这是否总体上是此控件的副作用，还是在PHP的LDAP模块中如何完成服务器控件的问题.

Another important note, if you are using LDAP paging it seems to interfere with this control. You cannot use paging and this control at the same time. I'm not sure if this is a side-effect of this control in general, or an issue with how server controls are done in PHP's LDAP module.