For Windows domain credentials to work the format of domainname\username is required which includes some non-numeric characters. On initial creation, anything can be entered as a username and the credentials function against multiple versions of Windows boxes (good!). However, when the domain account in use experiences a password change, I am unable to update the password in GSA. Error message is:
(Status code:400) Operation ‘Save Credential’ failed
Login name must not be empty and contain only alphanumeric characters
I tried removing all non-alphanumeric characters from the username and it was able to save/update the setting, confirming that it is indeed failing on a check for non-alphanumeric characters. HOWEVER, this is useless in an Windows domain (SMB) scan as the \ character at a minimum is required for successful authentication.
My guess is that someone clicked the wrong integrity checkbox when the field is being edited/updated via the GSA web gui. Is there a workaround for this (or a fix)? Due to the inability to change this password there is a cascading effect of monstrous proportions for scans to be corrected:
Create a new Windows domain credential with the updated password
Clone the targets because I can’t assign a new credential to an existing target (why?)
Edit and assign the new credential to the new cloned target list
Clone the scan task (again, because for some godforsaken reason updating the target list is not allowed on an existing scan)
I ran into a similar issue - scanning with AD Windows domain credentials is not intuitive. Glad to hear the actual authentication works, even though updating the password / username is broken.
we are aware of several issues with the username validation for the credentials. As I did mention in the Github issue fixing this isn’t an easy task because different systems have different policies. We are currently thinking about possible improvements but this will take some time.
The username field within the GSA allows to specify a login for domain accounts in the form of e.g.:
domainname\username or username@domain
Only on a subsequent update of the already created credentials (e.g. change password) the GSA is blocking the use of @ or \ within the login name by throwing a Login name must not be empty and contain only alphanumeric characters message.
This is for sure a bug / issue in a component of GVM as at least @ or \ needs to be supported in the login name.
After a quick research (0356381 is the current head of the openvas-manager-7.0 branch) it seems the initial report of @tbf2k18 was solved last year with the PR below (which now seems to supported / fully allowed _, -, \, . or @) and needs a new release of openvas-manager 7.0:
Any idea when a new release will be available, or where to find the release schedule? This issue has been causing us trouble and we’re anxious for the fix.
