"get writable" errors with "Logon failure" in some cases
jsdhasfedssad opened this issue · comments
Using the command get writable sometimes fails with "Logon failure". I do not know exactly what triggers this but I get this error when authenticating using regular low priviledge accounts but not when authenticating using DAs so this may be related to privileges or lack there of.
In the screenshot you can see that the credentials for domainuser1 are correct but that the command get writable still fails when authenticating using the same account. FYI. The account domainuser1 does not have write rights of any sort to any object:
Just to be certain, using the command get writable will list objects the authenticating account has GenericAll or GenericWrite rights on, correct? Perhaps WriteDACL too?
something weird happens with us :D
while running add computer same error but credentials valid
invalidCredentials - None - ERROR_LOGON_FAILURE: Logon failure: Unknown user name or bad password. - bindResponse - None
@jsdhasfedssad The username is different between your two commands
@embargod Please open your own issue, it's not related to the current issue
Ooops. You are correct. My bad!
What about the privileges? Will get writable list objects the authenticating account has GenericAll or GenericWrite rights on?Perhaps WriteDACL too?
It will output WRITE if you can write at least one property on the object and CHILD if you can create a child to the object. If you want to know exactly which properties you can write on the object, use --detail. E.g. if it outputs a WRITE permission on nTSecurityDescriptor it certainly means you have WRITEDACL .
If you want a Security Descriptor way of permissions you can always use get object --resolve-sd
This is an interesting feature. Would you say it can partially replace Bloodhound/Sharphound? At least when it comes to identify and abuse edges that grants you write access?
Is there a way of using get writable in combination with --detail on a single object? Not only filtered by type.
It seems some attributes cannot be written to regardless of access rights. For example the attributes name and badPwdCount. Are some attributes "protected"?
I get the below error when trying the --resolve-sd command. The account I use is a DA:
It can help to identify interesting rights yes. Especially the write create child which is not part of bloodhound edges if I'm not mistaken. But of course it doesn't replace the powerful graph db used by bloodhound.
You can't do it for a single object or use get object with attributes allowedAttributesEffective or allowedChildClassesEffective. You could also use resolve-sd.
Yes, some attributes are only writable by the system, not through ldap.
For your error can you add a print(self.control_enum) before l.254 in utils.py and show me the output?
Where can I read about "write child"? Googling this only turns up nasty stuff...
About the attributes only writable by the system, why are they listed as writable by BloodyAD?
Here is the output:
The exact term is create child and you can read more about it here: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/990fb975-ab31-4bc1-8b75-5da132cd4584
Because it just displays output of allowedAttributesEffective which will display all theoretically modifiable attributes except constructed attributes, see: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/c16a23d1-6847-4b25-9f6b-f09fc29e8627
Thank you, there was a change since python 3.11 on IntFlags str. Should be fixed in bloodyad 1.0.2
@jsdhasfedssad can you confirm your issue is fixed? otype filtering on user should be fixed too