Hmmm... what happens of we cant write back to the registry of the machine in question, do we not end up with yet another UUID (or should that be NonU UID)...
Thinking....
...
Still Thinking....
| Open-AudIT https://www.open-audit.org/phpBB3/ |
|
| The problem with UUID https://www.open-audit.org/phpBB3/viewtopic.php?f=9&t=3351 |
Page 1 of 1 |
| Author: | hm2k [ Wed Jun 03, 2009 9:03 pm ] |
| Post subject: | The problem with UUID |
As you probably are aware there are some issues with using UUID. 1. Duplicates - Cloned machines will have matching UUIDs. 2. Null - No UUID returns all F's or 0's. Proposed solution: Using a short bit of vbs we can generate a unique GUID... [code]Set TypeLib = CreateObject("Scriptlet.TypeLib") Wscript.Echo TypeLib.Guid [/code] http://www.microsoft.com/technet/script ... y0221.mspx Now we've generated one, we need to store it somewhere that will be accessible in the future. I'd suggest either an INI file or the more obvious choice of the registry. In production, it can check if the resource exists, if it does, use that, otherwise generate a new one as per the above. There is about a 1 in 3.5 trillion chance of a GUID collision, so no need to worry about that. What are your thoughts on this? Thanks. |
|
| Author: | A_Hull [ Thu Jun 04, 2009 1:52 am ] |
| Post subject: | Re: The problem with UUID |
Hmmm... what happens of we cant write back to the registry of the machine in question, do we not end up with yet another UUID (or should that be NonU UID)... Thinking.... ... Still Thinking....
|
|
| Author: | A_Hull [ Thu Jun 04, 2009 2:15 am ] |
| Post subject: | Re: The problem with UUID |
We do need to either tatoo the machine, or find some genuinely unique method. I suspect we need to use the current method, and try to write some form of tatoo back to the box... Then again, if the box is virtual, ... we are still stuffed if it is a cloned... if we clone the box after it is tatooed, we end up with two machines with the same UUID..... ... still thinking (....I think I can smell smoke... think I might be thinking tooo hard... ) |
|
| Author: | hm2k [ Thu Jun 04, 2009 2:50 am ] |
| Post subject: | Re: The problem with UUID |
It is a tough one... You could of course store the generated GUID in an ini file as I suggested if you can't write to the registry. The limitation to any software method is that once it's removed, it's gone. The only other method is to use hardware... You can't really use the MAC address, as you may use the same network interface on many machines (think wireless internet dongles), plus some machines have multiple interfaces, which do you choose? You could however generate some kind of hash based on the hardware configuration. This works especially well for Dell machines where you can include the asset tag/serial number, but not so well on machines where the configuration is identical. Others have tried using the HDD serial number, but this is faced with a similar issue, where sometimes it's not unique. ...it's a tough one... |
|
| Author: | Mark [ Thu Jun 04, 2009 7:46 am ] |
| Post subject: | Re: The problem with UUID |
What I've done for OAv2 is UUID + PC Name as the unique key. Still, if you format and reinstall AND give it the same name.... I account for this by having a flag in the System Table. You can set it to "production" (default), "retired", "maintenance" or "deleted". If you set it to something other than "production" BEFORE you next scan it (after formatting + same name), you'll be fine. Any improvement on this ? (for OAv2). |
|
| Author: | hm2k [ Thu Jun 04, 2009 10:33 am ] |
| Post subject: | Re: The problem with UUID |
UUID often returns all F's or all 0's so it's useless at times. UUID are duplicated when systems are cloned. ComputerName may be duplicated. Because of this, I don't think UUID+ComputerName isn't really unique enough... Plus, the result is only unique until someone changes the name of the computer... It may be worth noting that (If memory serves) you cannot have duplicate ComputerNames on a given domain or workgroup. This would mean, that at the very least you need "ComputerName.(DOMAIN|WORKGROUP)" instead of just ComputerName. I'd be still considering the idea of generating a GUID to be stored somewhere and using that... |
|
| Author: | Mark [ Thu Jun 04, 2009 12:09 pm ] |
| Post subject: | Re: The problem with UUID |
Maybe UUID+Name+(Domain|Workgroup) Bear in mind this tool is for (mainly) corporate environments. PCs should not be getting renamed very often (if at all). [quote]It may be worth noting that (If memory serves) you cannot have duplicate ComputerNames on a given domain or workgroup. Correct. Being a corporate type tool, we are "most" concerned with Domains. Therefore Name+Domain should be sufficiently unique. Add in UUID and I think we win. [quote]UUID are duplicated when systems are cloned. I can't remember, but I thought the UUID we used was pulled from the motherboard. Therefore a re-image would not affect it. [quote]I'd be still considering the idea of generating a GUID to be stored somewhere and using that... The idea is to be "zero footprint" on the PCs being audited. Nothing to install. Nothing left behind. Note - this is the aim, not necessarily the reality. |
|
| Author: | hm2k [ Thu Jun 04, 2009 6:59 pm ] |
| Post subject: | Re: The problem with UUID |
I'd assume it's UUID from Win32_ComputerSystemProduct. As per this URL: http://msdn.microsoft.com/en-us/library/aa394105(VS.85).aspx It says: [quote]The Win32_ComputerSystemProduct WMI class represents a product. This includes software and hardware used on this computer system. [quote]UUID Data type: string Access type: Read-only Universally unique identifier (UUID) for this product. A UUID is a 128-bit identifier that is guaranteed to be different from other generated UUIDs. If a UUID is not available, a UUID of all zeros is used. As you can see, it has no mention of where the UUID comes from, apart from software or hardware used on this computer system... not very helpful... UUID+Name+(Domains OR Workgroup) is still probably one of the most reliable ways to go, especially when you're dealing with computers within a domain, and some not. Others have suggested using the Windows installation timestamp, but that can may be cloned. |
|
| Author: | JayDee [ Thu Jun 04, 2009 11:06 pm ] |
| Post subject: | Re: The problem with UUID |
These are just some random thoughts on this topic: [quote]The idea is to be "zero footprint" on the PCs being audited. Nothing to install. Nothing left behind. This is NOT optional for me - I need a clean audit. How much of a real world problem is this - especially when the extended key being discussed is used? Even though some combinations can be duplicated does this happen on a large scale? I know I work for a small organization now but I have worked for much larger and I have never found this sort of duplication a problem. The addition of the "life status" flag (and a BIG cheer for that!!) would also seem to mitigate many difficulties. Are we ending up with a key that takes 75% of the screen and leaves very little room for useful data? Just my 2 cents. Thanks, John |
|
| Author: | hm2k [ Thu Jun 04, 2009 11:30 pm ] |
| Post subject: | Re: The problem with UUID |
If it's a clean audit you want, we'd need to use some kind of machine fingerprint based on hardware configuration. The real world problem is that sometimes UUID doesn't exist, and systems return all F's or all 0's meaning a collision is very likely if you stick purely to UUID. Other than that, it really depends what you're talking about. Of course a ComputerName collision is very possible, especially if machines are cloned. In the case of UUID it depends how it's created. If it's pulled from the hardware, it depends whether the manufacturer has ensured that the UUID is actually unique and not some random string they have cobbled together. Having said all this UUID isn't really the problem, when it's there. If it's not there, what do you use instead? A GUID/UUID consists of 32 hexadecimal digits, same as an MD5 hash. SHA-1 uses 40. So 75%? It depends on your resolution.  Perhaps a MD5 hash of ComputerName+(DOMAIN|WORKGROUP)+InstallDate is the answer... |
|
| Page 1 of 1 | All times are UTC + 10 hours |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|