Hi dear users,
Last year we met a performance bottleneck since we used NTLM authentication
against an Active Directory for 802.1X EAP-PEAP connections. According to your
suggestions, we decided to use NTLM authentication caching module to improve
the performance. Last week we deployed the change to our online PF. But soon
after that, IT team found their AD server rebooted several times.
With Microsoft developer's help, they finally find it is PF's sync script that
caused AD sever rebooting. Could you help to check if it is PF's sync script
/usr/lib/python2.7/site-packages/impacket/dcerpc/v5/drsuapi.py caused this bug
? If yes could you suggest how to fix this replication script ? Thank you very
very much.
The original response is as below:
///////
The problem was ntdsai was searching attribute for ATTRFULL type, but the
returned type was ATTRSIMPLEs, as they have different sizes, it brought heap
corruption and made lsass crashed, and the problem occurred when the DC
received replication request, so I took a further look on why the issue didn??t
occur on the other machine and why we cannot reproduce the issue in our lab,
then I found this code is only executed when the request doesn??t include
DRS_EXT_NONDOMAIN_NCS flag.
For Windows DC, only Win2000 doesn??t send this flag, and we already confirmed
there is no Win2k DC in the customer??s environment, so I checked the source
machine and found it was from a Linux machine: <our pf ip-masked>, the flag
sent from that machine was 0x5408000:
0:060> db pext+4
000001af`400617bc 00 80 40 05 00 00 00 00-00 00 00 00 00 00 00 00
..@.............
It means: DRS_EXT_STRONG_ENCRYPTION, DRS_EXT_GETCHGREQ_V6,
DRS_EXT_GETCHGREPLY_V6
I was curious about the byte order so I checked 0x00804005, which includes:
DRS_EXT_NONDOMAIN_NCS, DRS_EXT_GET_REPL_INFO, DRS_EXT_REMOVEAPI, DRS_EXT_BASE,
and this flag makes more sense?? from the code explanation I found:
// PORTABILITY WARNING: Since this structure is marshalled as a byte array,
// big-endian machines will need to do local byte-swapping.
The application on Linux maybe forgot add the flag ??DRS_EXT_NONDOMAIN_NCS??
and made the problem occurred.
///////
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users