joeware - never stop exploring... :)

More from the mailbag….

I just downloaded and tried your memberof utility, but I think I’m missing something.

What I want to do is – in the Windows logon script – determine if the logged on user is in a particular group so I can take a specific action.  The easy part has been to figure out this information, but the impossible part has been communicating that result back to the logon script in a way that it can handle.

Anyway, I saw this utility and thought it might have a way to do what I want.  So I downloaded it and ran it from the command prompt to check out what it does, and when I typed memberof and hit enter, I got a list which includes my name and all of the groups I belong to.  Then I tried memberof –group domainname\groupname to see if, by specifying the group, I could get a simple yea/nay that I’m in it or not.  I also tried the same command with a group I’m not in – and got the same results.  All I get back in every case is these two lines.

Security Principal: [GROUP] domainname\groupname

Group Memberships:

Of course, where is say “domainname” and “groupname” I specified the actual ones.  Also, I know I should be able to do this as a normal user, but I have domain admin rights and this is still what I get.

Am I just mistaken about what the tool does or am I missing some obvious syntax?  Any help is appreciated.

 

 

My response…

 

The -group and -computer switches are for if you want to specify looking at the memberof attribute of a specific group or computer, not to check for existence of that group or computer in the user’s memberof attribute.

You could pipe memberof’s output to findstr and then check that way, something like

[Thu 08/07/2008  9:33:29.70]
G:\new1\Dev\CPP\MemberOf>memberof

MemberOf V02.03.00cpp Joe Richards (joe@joeware.net) June 2006

Security Principal: [USER] TEST\$joe
Group Memberships:
  [Local Security] [Administrators] CN=Administrators,CN=Builtin,DC=test,DC=loc
  [Local Security] [DnsAdmins] CN=DnsAdmins,CN=Users,DC=test,DC=loc
  [Global Security] [Domain Admins] CN=Domain Admins,CN=Users,DC=test,DC=loc
  [Global Security] [Domain Users] CN=Domain Users,CN=Users,DC=test,DC=loc
  [Universal Security] [Enterprise Admins] CN=Enterprise Admins,CN=Users,DC=test,DC=loc
  [Universal Security] [Schema Admins] CN=Schema Admins,CN=Users,DC=test,DC=loc
  [Local Security] [Users] CN=Users,CN=Builtin,DC=test,DC=loc

[Thu 08/07/2008  9:34:21.31]
G:\new1\Dev\CPP\MemberOf>memberof |findstr /i “CN=Users,CN=Builtin,DC=test,DC=loc”

MemberOf V02.03.00cpp Joe Richards (joe@joeware.net) June 2006

  [Local Security] [Users] CN=Users,CN=Builtin,DC=test,DC=loc

[Thu 08/07/2008  9:34:30.29]
G:\new1\Dev\CPP\MemberOf>echo %errorlevel%
0

[Thu 08/07/2008  9:34:33.12]
G:\new1\Dev\CPP\MemberOf>memberof |findstr /i “CN=Users2,CN=Builtin,DC=test,DC=loc”

MemberOf V02.03.00cpp Joe Richards (joe@joeware.net) June 2006

[Thu 08/07/2008  9:34:38.90]
G:\new1\Dev\CPP\MemberOf>echo %errorlevel%
1

  joe

http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

Another one from the mailbag…

adfind -b cn=ZZZ,ou=Users,ou=AAA,ou=XXX,ou=ad,DC=YYY,DC=com dn msexchmailboxsecuritydescriptor publicDelegates publicDelegatesBL -f “(&(objectcategory=person)(objectclass=user))” -sddc++ -resolvesids >> C:\textfile.txt

what an i missing to pull permissions off a mailbox that they user has applied on the client. Say I have an account reviewer to my contacts in my mailbox

Thanks for any help

 

This one needed a bit of a long winded answer, here is part of what I responded with…

Unfortunately for your question you are running into the crapissions that Exchange uses and calls the Exchange permissioning system. Off the top of my head there are five separate and distinct ways in which permissions are applied in Exchange. Its been a bit since I looked at these but let me regurgitate what I recall…

First off this is Exchange 2000/2003, I haven’t played with 2007 but I expect it hasn’t changed.

The first set of permissions are applied in the configuration “partition/naming context/container” on the Exchange objects at the ORG level and below on the nTSecurityDescriptor attribute. These are worked with with any AD Permissions tool. These permissions are used for Exchange for managing the config stuff but also in the case of “Send As / Receive As” are also translated to Full Mailbox permissions on the mailboxes. I.E. If you want to give someone full mailbox control over all mailboxes in a DB, SG, Server, AG, or the Org you give them “Send As / Receive As” over that level of the objects in the configuration container and they will show up as “inherited” permissions on the mailbox itself and will be reflected in the second set of permissions – the msExchMailboxSecurityDescriptor.

The second set of permissions are in the normal domain partition or at least reflected there in the msExchMailboxSecurityDescriptor attribute. This attribute is only authoritative (and can be set) for a mailbox until the mailbox has been instantiated in the store, once that occurs, this attribute *may* reflect a copy of the permissions in the store. I have seen cases where this attribute does not properly reflect what is in the store for the mailboxes. Usually though it seems right. Anything that shows as inherited is coming from the config NC as mentioned above, anything explicit was applied directly to the user. You cannot inherit permissions to this through the domain NC OU structures. You can work with these permissions via CDOEXM with info from the following link – http://support.microsoft.com/kb/310866

The third set of permissions are maintained in the normal domain partition on the nTSecurityDescriptor. This is where you would add Send As / Receive As when you want it to work actually as Send As / Receive As instead of being a full mailbox control. These can be inherited down through the OU structure. Not sure why MSFT even did this but they did. Seemed like an unnecessary complication on a system that was already too complicated. If you have Send As you can send as the person. These are worked with with any AD Permissions tool.

The fourth set of permissions are maintained in specific attributes such as the publicDelegates. This allows you to send mail on behalf of the person. You get no permissions over the mailbox folders unless specifically granted. The GUI in Outlook can really confuse people on this. This is also very special in that there is the AD component and the Store component and they are separate and can get out of sync. This was a common problem (more common than people may realize) for folks with multi-domain forests when their outlook client connected to a GC that wasn’t a DC for the domain the user was in. One side of that permission (in the store) could be set up or removed, but not the AD side. This can cause all sorts of funky issues with your public delegates. This was the reason I fought for and eventually got the change to DSACCESS to have it try to give you a GC that is a DC for the domain your user account was in.

The fifth and important to you set of permissions aren’t really permissions so much as they are MAPI properties inside the mailbox on the folders, etc that reside there. This information is NOT in any way shape or form mapped back into AD. The only way to get that info is to contact the mailbox and enumerate the folders via CDO. Take a look at
http://support.microsoft.com/kb/295558

 

Hope this helps.

   joe

This was part of a message in my inbox, it was about using OldCmp and this was one of the questions.

We want to move all the users into the appropriate OU based on the first two digits of their username. Can we move users into an OU?

Something like: -move –b ou=Carlisle, dc=domain, dc=com –af “(name=ca*)”

My response

Do you want to move any users with that prefix or do you want to do it based on their age?

If you just want to move them regardless, use adfind output piped to admod to do it… Something like

adfind -b ou=blah,dc=domain,dc=com -f “name=ca*” -dsq | admod -move ou=newparent,dc=domain,dc=com -upto xxx

where xxx is the max number you want to move at once. If you don’t know how many there are but want to move them all, you can use -unsafe instead of -upto.

Now if you do want to do it based on age as well, then you will want to use oldcmp and would look something like

oldcmp -move -users -age XX -newparent ou=newparent,dc=domain,dc=com -f “(name=ca*)”

  joe

http://www.tgdaily.com/content/view/38817/108/

Brian wrote up a great little article on the steps he took in troubleshooting a service that was crashing, I highly recommend this article.

 

http://briandesmond.com/blog/archive/2008/08/05/msdtc-exits-on-pdce-transfer.aspx

Got this question in the mailbag today, thought I would share as it is common question

I’m looking for a reference or some lead on how I can comprehensively report the date of the last time all user accounts passwords in AD were reset.  I was wondering if you could point to something out there.

My response

You can dump when accounts had their password changed, but that includes password changes as well as password resets… i.e. if someone changed a password by supplying the old password or if there was an administrative action. There is no way outside of the audit log to determine when accounts were reset only.

If you just need to know when all passwords were last changed, you can do something like

adfind -b dc=domain,dc=com -f “&(objectcategory=person)(objectclass=user)” pwdlastset -tdcs

A pretty common issue out there in the real world is an error of something like

“There are multiple accounts with name XXX/YYYYYYYYYY of type DS_SERVICE_PRINCIPAL_NAME” or maybe that last bit is “of type 10”

floating about.

The general guidance is to find the objects with the same SPNs and clean all but one of them up. Some people get touchy about this because they think cleaning these dupes up will break kerberos… News flash if you are seeing these errors, Kerberos already is broken for those objects. Nuff said; clean them up.

Well then you get the folks who say “Well I searched like you told me to (or like KB321044 told me to) and I couldn’t find but the one object with that SPN set.”

The problem with this is that not all SPNs are explicitly registered in Active Directory. So the guidance from many people as well as from KB321044 is not altogether good enough. KB321044 hints to a solution for the problem but it is such an afterthought in the article most people blow right past it, specifically the line that says “Note If you do not receive the expected result, try searching for ” HOST/” as opposed to searching only for the exact SPN in the event ID.”

I think they should add a whole section to that KB concerning what I am about to write below, in fact, just append this blog article to any note or anything else you respond to when telling someone how to troubleshoot this. Think of this article as KB321044++…

So back to point… I said, and meant it when I said it, that not all SPN’s are explicitly registered in Active Directory. Microsoft did something that I personally think was very intelligent. They set up a bunch of SPN types that by default any HOST object can automatically be tied to even if they aren’t explicitly stated – i.e. these types will be mapped to HOST/whatever when they are encountered by AD. Currently in my Windows 2008 Test forest, that list of types that map to HOST is

• alerter
• appmgmt
• browser
• cifs
• cisvc
• clipsrv
• dcom
• dhcp
• dmserver
• dns
• dnscache
• eventlog
• eventsystem
• fax
• http
• ias
• iisadmin
• mcsvc
• messenger
• msdtc
• msiserver
• netdde
• netddedsm
• netlogon
• netman
• nmagent
• oakley
• plugplay
• policyagent
• protectedstorage
• rasman
• remoteaccess
• replicator
• rpc
• rpclocator
• rpcss
• rsvp
• samss
• scardsvr
• scesrv
• schedule
• scm
• seclogon
• snmp
• spooler
• tapisrv
• time
• trksvr
• trkwks
• ups
• w3svc
• wins
• www

That means if an application or machine asks for says CIFS/machinename or CIFS/machinename.domain.com Active Directory will look up that specified SPN but also HOST/machinename or HOST/machinename.domain.com. This is why Microsoft has that small note in the article… Because if the SPN has type of any of the above types, you very likely WON’T find the SPN by searching for the specific SPN specified in the event log entry.

You too can easily see which HOST mappings you have by running the following command with my very own AdFind command line tool

adfind -config -f spnmappings=* spnmappings

The output looks like this on my brand spanking new Windows Server 2008 Server…

C:\>adfind -config -f spnmappings=* spnmappings

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: TROUBLE-DC1.trouble.loc:389
Directory: Windows Longhorn
Base DN: CN=Configuration,DC=trouble,DC=loc

dn:CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=trouble,DC=loc
>sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,ne
tman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trk
svr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc

1 Objects returned

Quick Note: To my friends at MSFT who I know for sure read the blog… Eric, Brett, Moon, Nathan, and others…. The name of the domain is indeed “Trouble”, this is not in any way shape or form a reference to Microsoft nor Windows Server 2008. Seriously. This is a reference to my black cat who was walking across my keyboard whapping me in the face with her tail as I made that domain and was thinking, what should this domain be named? <WHAP>

<…and we’re back>

So when you are looking for these duplicated, just expand the query to look for the specific SPN you want as well as the SPN with the type replaced with HOST. Actually Microsoft’s QuerySPN.VBS script should do exactly that but it doesn’t.

I say, don’t even bother with that script, don’t bother with LDIFDE (can ya say yuck?), and don’t even bother with LDP (even though it rocks in general); just use AdFind to go looking for these objects. Do something like

adfind -sc c:computername

Why will just looking for the computer name work? Because almost certainly (like 99.999% chance) the computer name is duplicated in your forest and even though you may not be using WINS (hahahahaha sure…), you still can’t duplicate machine names in a forest. They have to be unique so you can have unique SPNs for the short host name versions. For example, one of my Windows Server 2008 machines has the following SPNs

dn:CN=TROUBLE-DC1,OU=Domain Controllers,DC=trouble,DC=loc
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/TROUBLE-DC1.trouble.loc:50000
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/TROUBLE-DC1:50000
>servicePrincipalName: TERMSRV/TROUBLE-DC1
>servicePrincipalName: TERMSRV/TROUBLE-DC1.trouble.loc
>servicePrincipalName: NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/TROUBLE-DC1.trouble.loc
>servicePrincipalName: Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/TROUBLE-DC1.trouble.loc
>servicePrincipalName: GC/TROUBLE-DC1.trouble.loc/trouble.loc
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc/TROUBLE
>servicePrincipalName: HOST/TROUBLE-DC1
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc/trouble.loc
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2/02cd7861-be73-4ef5-9892-fcd35231ac27/trouble.loc
>servicePrincipalName: ldap/02cd7861-be73-4ef5-9892-fcd35231ac27._msdcs.trouble.loc
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc/TROUBLE
>servicePrincipalName: ldap/TROUBLE-DC1
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc/trouble.loc

 

Notice that some of those SPNs do not have a FQDN in them… Specifically

>servicePrincipalName: TERMSRV/TROUBLE-DC1
>servicePrincipalName: HOST/TROUBLE-DC1
>servicePrincipalName: ldap/TROUBLE-DC1

These all would have collisions if you had the same machine name in two domains in the same forest. Hence any app that used them would fail to use kerberos for the authentication because AD cannot map the name to a unique object.

So anything else? I think not, this is good… What did we learn?

1. Don’t duplicate machine names in a forest, period.
2. If you have duplicate SPN issues, use AdFind to find all computers with the name in the SPN.
3. Duplicate SPNs means kerberos is already not working right for those machines so cleaning it up isn’t going to break anything worse.

 

    joe