janstarke / ntdsextract2

This aims to be a collection of tools to forensically analyze Active Directory databases
https://www.bdosecurity.de
GNU General Public License v3.0
16 stars 2 forks source link

4 feature request display dn #22

Closed janstarke closed 2 weeks ago

janstarke commented 3 weeks ago

optionally display the DN in user, group or computer mode.

@TheraNinjaCat: Can you please try if that fits your needs?

TheraNinjaCat commented 3 weeks ago

The distinguished name looks good when it's present, there are some user and computer rows where it's just completely absent, and there were no row outputs for groups that even had it present at all. It Potentially it wasn't able to complete a part of it so it is set as null? I think it may be better to output null rather than omitting the field if the -D flag has been set. On the topic, I've also found some rows with a null SID which I didn't think was really possible. While I can't share the full dataset for you to test with, is it potentially possible to increase verbosity to identify why the distinguished_name or SID aren't present, and I may be able to provide that diagnostic?

On the topic of odd output, I think this might need to be it's own separate issue, but I've got a large number of identical account_expires values that don't make sense, namely 01-01-1601T00:00:00+0000 and 14-09-+30828T02:48:05+0000, while the former seems to potentially be the result of parsing a zero-value, I don't know what to make of the latter.

janstarke commented 2 weeks ago

I changed to code to deserialize a None; but I cannot test how this looks like, because I currently have no sufficient test data. Can you please give it a try?

I also added some logging to object_tree_entry.rs, lines 96-118

Regarding the DateTime stuff I created a new ticket :+1:

TheraNinjaCat commented 2 weeks ago

I've just run this on both user and group with the flags -D -F json-lines -vvv and have the following outputs: user with DN: {"sid":"valid-500","distinguished_name":"cn=Administrator,cn=Users,dc=valid,cn=valid,cn=valid,cn=valid","user_principal_name":"Administrator@valid","rdn":"Administrator","sam_account_name":"Administrator","sam_account_type":"SAM_USER_OBJECT","user_account_control":"valid","logon_count":2,"bad_pwd_count":1,"admin_count":1,"is_deleted":false,"primary_group_id":512,"primary_group":"Domain Admins","member_of":["valid"],"comment":null,"record_time":"valid","when_created":"valid","when_changed":"valid","last_logon":"valid","last_logon_time_stamp":"valid","account_expires":"01-01-1601T00:00:00+0000","password_last_set":"valid","bad_pwd_time":"valid"} user without DN: {"sid":"valid","distinguished_name":null,"user_principal_name":null,"rdn":"valid","sam_account_name":"valid","sam_account_type":"SAM_USER_OBJECT","user_account_control":"valid","logon_count":0,"bad_pwd_count":0,"admin_count":null,"is_deleted":false,"primary_group_id":513,"primary_group":"Domain Users","member_of":["valid"],"comment":null,"record_time":"valid","when_created":"valid","when_changed":"valid","last_logon":"01-01-1601T00:00:00+0000","last_logon_time_stamp":null,"account_expires":"01-01-1601T00:00:00+0000","password_last_set":"valid","bad_pwd_time":"01-01-1601T00:00:00+0000"} any group: {"sid":"valid","user_principal_name":null,"rdn":"valid","sam_account_name":"valid","sam_account_type":"SAM_GROUP_OBJECT","user_account_control":null,"logon_count":null,"bad_pwd_count":null,"admin_count":null,"is_deleted":false,"primary_group_id":null,"primary_group":null,"member_of":[],"comment":null,"record_time":"valid","when_created":"valid","when_changed":"valid","last_logon":null,"last_logon_time_stamp":null,"account_expires":null,"password_last_set":null,"bad_pwd_time":null} (I have redacted any non-default/sensitive data with valid, just know that they were values that made sense)

So it is always including distinguished_name as null if it is not present for users, but something strange is still going on with groups. I also ran it without -D and it correctly does not display the DN.

In terms of the error log, with -v, it is big (this is a large domain file), over 230,000 lines of warnings. The vast majority are of this: I expected to find an entry for backward link X; but there was none. I'll ignore that entry. (or the same but forwards link). Prior to any of those there is ~8000 that look like no object category for <item> (id=int/row=int), the item name seems to largely be an RDN however there are strange entries of numbers, for example one that is $ROOT_OBJECT$, and then one each for each portion of the domain name. With -vvv, the following debug entries from your new logging were found: (1) libntdsextract2::object_tree_entry: found the object tree root (1) libntdsextract2::object_tree_entry: hiding the $ROOT_OBJECT$ item But beyond those, there were no additional debug statements.

Also potentially relevant, these have been in all the logs:

no support for LONG columns yet, generating a random value
no support for LONG columns yet, generating a random value
I don't know how to extract GUIDs from Long
no support for LONG columns yet, generating a random value
no support for LONG columns yet, generating a random value
no support for LONG columns yet, generating a random value
I don't know how to extract GUIDs from Long
no support for LONG columns yet, generating a random value
I don't know how to extract GUIDs from Long
I don't know how to extract GUIDs from Long
I don't know how to extract GUIDs from Long
janstarke commented 2 weeks ago

the group seems to be working now (at least for me). Problem was that the code partially ignored the --include-dn flag