For TLS versions up to (including) 1.2, there are three DH versions: anonymous (ADH), fixed and ephemeral (DHE - see here for a quick description).
TLSv1.3 supports only DHE, so by default, your scenario does not work with TLSv1.3.
For <TLSv1.3, as @dave_thompson_085 has already pointed out, ADH can be selected (or provided as an option) in the 'ClientHello' message of the TLS protocol. 'ClientHello' is the first message that initiates the TLS negotiation between the client and the server (see a quick description here). After that point you can't change the DH version used.
In your scenario, an authenticated DH version is selected during step 1 (the server sends its certificate to the client after it receives the 'ClientHello' message from the client - the attacker just forwards the packets between the client and the server); you cannot change the DH version in step 4 (because the TLS negotiation has moved on from the initial 'ClientHello' message).
Alternative scenario 1: client sends the 'ClientHello' with e.g. DHE selected (ADH can be an option too, it doesn't matter in this scenario), the attacker intercepts the message, sends the 'ClientHello' to the server with ADH selected, the server rejects it (because you said it only accepts authenticated DH)
Alternative scenario 2: client sends the 'ClientHello' with e.g. DHE selected (but does not allow ADH as an option), the attacker intercepts the message, sends the 'ClientHello' to the server with ADH selected (let's assume the server allows it), server returns a message with the ADH suite selected, the client rejects it (because it does not support ADH) and closes the connection
Alternative scenario 3: client sends the 'ClientHello' with e.g. DHE (but provides the option to use ADH), the attacker intercepts the message and initiates a full MitM attack by establishing two ADH connections, one with the server and one with the client. Assuming that the server accepts ADH, this is the only scenario that can work (of course, this is well documented, so no surprises here).
So, aside from the case where both the client and server accept ADH, every other scenario is not feasible.