Export (0) Print
Expand All

3.1.4.2 Netlogon Negotiable Options

As part of the session-key negotiation, the client and server use the NegotiateFlags parameter of NetrServerAuthenticate2 or NetrServerAuthenticate3 to negotiate support for the following options. The client offers an initial set of capabilities through the NegotiateFlags parameter to the server as input. The server then selects the capabilities acceptable to it. The capabilities that are supported by the server are combined with the capabilities supported by the client by performing a bit-wise AND; the result of the operation is returned to the client as output, as detailed in sections 3.5.4.4.2 and 3.5.4.4.3. The client MUST inspect the returned negotiation capabilities to determine whether server-selected capabilities are supported by the client, and that all of the capabilities required by the client are returned by the server. For example, a client could be configured outside the protocol to require strong-key support; if the server did not offer strong-key support, the client SHOULD reject the server.

If NT4Emulator is set to TRUE and bit U has not been set in NegotiateFlags as input, then the server MUST return 0 for bits J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, and Y in the output of the NegotiateFlags parameter.

The following options are negotiable between the client and the server as part of the session-key negotiation. An option is TRUE (or set) if its value is equal to 1.


0

1

2

3

4

5

6

7

8

9
1
0

1

2

3

4

5

6

7

8

9
2
0

1

2

3

4

5

6

7

8

9
3
0

1

0

Y

X

0

0

0

0

W

0

0

V

U

T

S

R

Q

P

O

N

M

L

K

J

I

H

G

F

E

D

C

B

A

Where the negotiable options are defined as the following:

Option

Meaning

A

Not used. MUST be ignored on receipt.

B

Windows NT 3.5 operating system BDCs persistently try to update their database to the PDC's version once they get a notification indicating that their database is out-of-date. Presence of this flag indicates support for this behavior. Server-to-server only.

C

Supports RC4 encryption.

D

Not used. MUST be ignored on receipt.

E

Supports BDCs handling CHANGELOGs. Server-to-server only.

F

Supports restarting of full synchronization between DCs. Server-to-server only.

G

Does not require ValidationLevel 2 for nongeneric passthrough.

H

Supports the NetrDatabaseRedo (Opnum 17) functionality (section 3.5.4.6.4).

I

Supports refusal of password changes.

J

Supports the NetrLogonSendToSam (Opnum 32) functionality.<86>

K

Supports generic pass-through authentication.<87>

L

Supports concurrent RPC calls.<88>

M

Supports avoiding of user account database replication.<89> Server-to-server only.

N

Supports avoiding of Security Authority database replication.<90> Server-to-server only.

O

Supports strong keys.<91>

P

Supports transitive trusts.<92>

Q

Not used. MUST be ignored on receipt.

R

Supports the NetrServerPasswordSet2 functionality.<93>

S

Supports the NetrLogonGetDomainInfo functionality.<94>

T

Supports cross-foresttrusts.<95>

U

Supports neutralizing Windows NT 4.0 operating system emulation. Note that when this flag is negotiated between a client and a server, it indicates that the server SHOULD ignore the NT4Emulator ADM element.<96>

V

Supports RODC pass-through to different domains.<97>

W

Supports AES encryption (128 bit in 8-bit CFB mode) and SHA2 hashing as specified in sections 2.2.1.3.3, 3.1.4.3, 3.1.4.4, and 3.3.<98>

X

Not used. MUST be ignored on receipt.

Y

Supports Secure RPC.<99>

All other bits MUST be set as specified in the NegotiateFlags description and MUST be ignored on receipt.

 
Show:
© 2015 Microsoft