At this time there is no way to set the encryption types set in the keytab at the time of joining.
Enabling AES256 within AD (Active Directory) forces the use of AES256 even when other encryption types are specified within the keytab.
To remove the unwanted encryption types please use the ktutil command within vas to remove the unwanted types from the keytab (see man pages for vas).
With that said, the reference to non-AES encryption types in the keytab doesn't necessarily mean that QAS (Quest Authentication Services) will use them.
If TCPDump is performed of the interaction, one should be able to confirm which encryption method is being used, which should be AES.
The keytab entries are similar to languages, from a "plain" password QAS can "translate" it to any language desired and put it in the keytab. That doesn't mean that QAS will use it or that Active Directory would accept it, it just exists.
In the case where Active Directory is configured to use RC4, AES128, and AES256 and the host keytab contains those three encryptions, the default_etypes would limit what types QAS would use to talk to AD.
If RC4 is one of the encryption types, as long as it is not set, QAS would never use that type, however, that is half of the "story", this doesn't control what AD might talk to QAS with, that is configured within AD in the environment.
QAS could be set to use only AES, no RC4 entries whatsoever, yet if the vastool klist -v output still has RC4 in it there is nothing QAS can do about it.
To better explain this, please see the following example:
User A in domain A wants to log into a QAS host in domain B.
User A is AES enabled and the QAS host in domain B is AES enabled.
User A gets their AES krbTGT from domain A. Here is the issue.
User A will use that ticket to request a cross-realm TGT for domain B. The request's encryption type is what the request is made in, from the original TGT.
Whatever active directory provides is what QAS will use so there could be a cross realms ticket that is RC4 that is used as QAS doesn't process the ticket, it's just a hand-off back to AD to request a TGS for the QAS host.
The response comes back down in AES and QAS uses AES to decrypt it then validate the user.
So even though the encryption used by QAS is in AES for the ticket it doesn't mean AD will use that encryption type after the ticket is created.
The long-story of this is that AD needs to be set up correctly to ensure that intermediate tickets are set to use AES (if AES is desired) before limiting QAS to AES otherwise it could start failing.
From the QAS side of things, the default_etypes should do this regardless of keytab entries.