Non-chromeos device serial number enterprise enrollment

[Ian Bloss]

My organisation is moving to chromebooks for our freshman students next year, while I have three previous years of students that have windows based devices.

I have successfully created my own images of chromiumos that are compatible with the 2 different laptop brand/models that are currently in circulation. I've then had my test machines successfully enroll into the enterprise domain and even sync user policies perfectly but, enrollment doesn't get the devices real serial number and instead generates some random serial to fill it's place like "nonchrome-1554234". It does however get the correct MAC addresses for networking devices.

From what I've read, normal chromeos devices use coreboot, and reads the serial number from the coreboot bios. I can get the board information via the /sys/ filesystem (/sys/devices/virtual/dmi/id).

I was hoping someone could point me into the right direction where maybe I could patch a switch that'll allow an alternative method of collecting machine info for enterprise enrollment.

[Mattias Nissler]

The code that generates the nonchrome-XYZ serial numbers is from https://chromium.googlesource.com/chromiumos/platform2/+/master/login_manager/init/machine-info.conf and is installed in /etc/init/machine-info.conf

For background, the dump_vpd_log command used on Chrome hardware doesn't produce anything useful elsewhere, so we added the nonchrome-XYZ hack (mainly to easy testing in VMs). If you come up with a better solution that's expected to work for the majority of non-Chrome hardware cases, feel free to submit a patch :)

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Ian Bloss]

Awesome, this gives me something to work with. I will post commit if I find a more universal solution, but I have a pretty good idea of what I'm going to do.

[David Hendricks]

If the nonchrome-XYZ hack Mattias mentions does not work, I can also help you try to modify your firmware a little bit to make "dump_vpd_log" work correctly.

Not all hardware will be easy to work with. However, if we're lucky we can add the small "vital product data" (VPD) region to your firmware ROM which is used in enterprise enrollment.

[Mike Frysinger]

don't x86 BIOSs tend to have serial numbers in them that dmidecide can show? we could add logic for that behind a use flag that the generic boards would enable.
-mike

[Mattias Nissler]

On Tue, Mar 31, 2015 at 9:55 AM, Mike Frysinger <vap...@chromium.org> wrote:

don't x86 BIOSs tend to have serial numbers in them that dmidecide can show? we could add logic for that behind a use flag that the generic boards would enable.

Yup, that's certainly an option to consider. One concern is VMs and broken BIOSes that report a fixed value regardless of device, in which case we'll get serial number collisions, which will break some server-side assumptions. If we enabled this for generic boards, then care needs to be taken to not break stuff in VMs at least.

FWIW, dmidecode on a Falco says "Serial number: 123456789" in the "System Information" record. The correct serial number is present on my workstation though.

Finally, note that the enterprise stuff doesn't technically require that the value used by the serial number, but it should be a stable and unique hardware identifier.

[David Hendricks]

On Tue, Mar 31, 2015 at 12:55 AM, Mike Frysinger <vap...@chromium.org> wrote:

don't x86 BIOSs tend to have serial numbers in them that dmidecide can show? we could add logic for that behind a use flag that the generic boards would enable.

Sort of... It's a free-form string that is often filled with "To Be Filled By O.E.M." or "1234567890".

MAC address of eth0 would might be a good alternative, though, since it's also going to be tied with the IP address on the network.

[Ian Bloss]

My plan was to write a helper bash script that check in /sys/devices/virtual/id or /proc/sys/.... for model/serial/(service tag if applicable)

If model information can't be found there just fall back to "chrome-xyz"

This allows anyone to easily drop in an alternative method for detection or tweak it. The fall back allows for vms (I don't know of they report their own info via sysfs)

Both of the models of machines that we have do report their model, S/N, and service tag.

[Mattias Nissler]

That's sounds like a sane approach. FWIW, I'm happy to review code changes and verify they don't break the VM use cases I'm aware of.

[Gwendal Grignou]

Mattias, 

You added and removed code to retrieve the main storage serial number for unique identification, and removed it (chromium:199720). Would it help in this case?

Gwendal.

[Mattias Nissler]

On Tue, Mar 31, 2015 at 7:26 PM, Gwendal Grignou <gwe...@chromium.org> wrote:

Mattias, 

You added and removed code to retrieve the main storage serial number for unique identification, and removed it (chromium:199720). Would it help in this case?

We are indeed using the root disk serial number as well, but for a different purpose. The feature that uses the root disk serial number is forced re-enrollment, which is used to determine whether a device should re-enroll after hardware reset. For this, we store information in the cloud. That data is not keyed by serial number, but by an identifier that is opaque and unpredictable to the server. The identifier is essentially a hardware fingerprint, and the root disk serial number is used as on input for the calculation.

I think using the root disk serial number as a fallback would make sense here - but obviously we can't expect disk serial numbers to be present 100% of the time either.

FWIW, https://chromium-review.googlesource.com/#/c/199720 just removed an obsolete code path that was replaced by this: https://chromium.googlesource.com/chromiumos/platform/login_manager/+/master/init/ui-collect-machine-info.conf

[Skazy161 Skazy161]

"'Mattias

Здравствуй! Денежный перевод прошел быстро и успешно. На скрине ты можешь увидеть присланную тобой сумму. Кстати, по-моему мы договаривались о меньшей сумме! Или я не прав?




Среда, 1 апреля 2015, 11:34 +02:00 от "'Mattias Nissler' via Chromium OS discuss" <chromium-...@chromium.org>:

On Tue, Mar 31, 2015 at 7:26 PM, Gwendal Grignou <> wrote:

Mattias, 

You added and removed code to retrieve the main storage serial number for unique identification, and removed it (chromium:199720). Would it help in this case?

We are indeed using the root disk serial number as well, but for a different purpose. The feature that uses the root disk serial number is forced re-enrollment, which is used to determine whether a device should re-enroll after hardware reset. For this, we store information in the cloud. That data is not keyed by serial number, but by an identifier that is opaque and unpredictable to the server. The identifier is essentially a hardware fingerprint, and the root disk serial number is used as on input for the calculation.

I think using the root disk serial number as a fallback would make sense here - but obviously we can't expect disk serial numbers to be present 100% of the time either.

FWIW, just removed an obsolete code path that was replaced by this: 

Gwendal.

On Tue, Mar 31, 2015 at 7:56 AM, 'Mattias Nissler' via Chromium OS discuss <> wrote:

That's sounds like a sane approach. FWIW, I'm happy to review code changes and verify they don't break the VM use cases I'm aware of.

On Tue, Mar 31, 2015 at 4:04 PM, Ian Bloss <> wrote:

My plan was to write a helper bash script that check in /sys/devices/virtual/id or /proc/sys/.... for model/serial/(service tag if applicable)

If model information can't be found there just fall back to "chrome-xyz"

This allows anyone to easily drop in an alternative method for detection or tweak it. The fall back allows for vms (I don't know of they report their own info via sysfs)

Both of the models of machines that we have do report their model, S/N, and service tag.

On Mar 31, 2015 4:09 AM, "David Hendricks" <> wrote:

On Tue, Mar 31, 2015 at 12:55 AM, Mike Frysinger <> wrote:

don't x86 BIOSs tend to have serial numbers in them that dmidecide can show? we could add logic for that behind a use flag that the generic boards would enable.

Sort of... It's a free-form string that is often filled with "To Be Filled By O.E.M." or "1234567890".

MAC address of eth0 would might be a good alternative, though, since it's also going to be tied with the IP address on the network.

-mike

On Mar 31, 2015 00:46, "David Hendricks" <> wrote:

If the nonchrome-XYZ hack Mattias mentions does not work, I can also help you try to modify your firmware a little bit to make "dump_vpd_log" work correctly.

Not all hardware will be easy to work with. However, if we're lucky we can add the small "vital product data" (VPD) region to your firmware ROM which is used in enterprise enrollment.

On Mon, Mar 30, 2015 at 6:12 AM, Ian Bloss <> wrote:

Awesome, this gives me something to work with. I will post commit if I find a more universal solution, but I have a pretty good idea of what I'm going to do.

On Mon, Mar 30, 2015 at 5:10 AM, Mattias Nissler <> wrote:

The code that generates the nonchrome-XYZ serial numbers is from and is installed in /etc/init/machine-info.conf

For background, the dump_vpd_log command used on Chrome hardware doesn't produce anything useful elsewhere, so we added the nonchrome-XYZ hack (mainly to easy testing in VMs). If you come up with a better solution that's expected to work for the majority of non-Chrome hardware cases, feel free to submit a patch :)

On Fri, Mar 27, 2015 at 5:21 PM, Ian Bloss <> wrote:

My organisation is moving to chromebooks for our freshman students next year, while I have three previous years of students that have windows based devices.

I have successfully created my own images of chromiumos that are compatible with the 2 different laptop brand/models that are currently in circulation. I've then had my test machines successfully enroll into the enterprise domain and even sync user policies perfectly but, enrollment doesn't get the devices real serial number and instead generates some random serial to fill it's place like "nonchrome-1554234". It does however get the correct MAC addresses for networking devices.

From what I've read, normal chromeos devices use coreboot, and reads the serial number from the coreboot bios. I can get the board information via the /sys/ filesystem (/sys/devices/virtual/dmi/id).

I was hoping someone could point me into the right direction where maybe I could patch a switch that'll allow an alternative method of collecting machine info for enterprise enrollment.

--
--
Chromium OS discuss mailing list:

View archives, change email options, or unsubscribe:

To unsubscribe from this group and stop receiving emails from it, send an email to .

--
--
Chromium OS discuss mailing list:

View archives, change email options, or unsubscribe:

To unsubscribe from this group and stop receiving emails from it, send an email to .

--
--
Chromium OS discuss mailing list:

View archives, change email options, or unsubscribe:

--
--
Chromium OS discuss mailing list:

View archives, change email options, or unsubscribe:

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:

To unsubscribe from this group and stop receiving emails from it, send an email to .

<base target="_self" href=" /> </div> </div> </div> </blockquote> <br/> </BODY></HTML>

[Ryan Stockham]

Ian...Unfortunately I don't have any information to help you, but I do have a question for you.  I'm trying to do the same thing for my school.  I've created my own images that work well with some of our machines, however I can't get any of mine to enroll into my enterprise.  Did you have to do anything special to make this work?  Any time I do it, I get some sort of a network error and it fails.  I'm doing it before I ever login a user, etc just like you're supposed to, but it just doesn't work.  I also have licenses available, so that's not the issue either.  Just curious if you had to do any additional steps outside of standard OS compiling to make this work with your images.  Thanks!

[Mattias Nissler]

Ryan,

If you give us the exact error message, we'll probably be able to tell you what's going wrong.

Cheers,

Mattias

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:

http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

--

Mattias Nissler | Software Engineer | mnis...@google.com

Google Germany GmbH

ABC-Str. 19

20345 Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

Registergericht und -nummer: Hamburg, HRB 86891

[Ryan Stockham]

Wow...thanks for the quick response!  Here is the exact error I receive after trying to enroll and entering my organization username and password:  "Oops! A network communication problem occurred during authentication.  Please check your network connection and Try Again"  Of course however the network connection is fine and my other "actual" chromebooks can enroll just fine with no issues.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.

[Mattias Nissler]

The "during authentication" part suggests that we weren't able to get our OAuth token that will enable us to talk to the management service. One potential thing to check is that you have usable API keys - see here for more information: https://www.chromium.org/developers/how-tos/api-keys

That's still just a stab in the dark (although a more informed one). One way to understand better what's going on is running chrome with this additional command line flag: --log-net-log=/tmp/net.log

This will cause all network request to be logged to /tmp/net.log, which you can load into chrome://net-internals (on any chrome browser), locate the request that failed, and hopefully find some more details on what caused the failure.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

--

Mattias Nissler | Software Engineer | mnis...@google.com

Google Germany GmbH

ABC-Str. 19

20345 Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

Registergericht und -nummer: Hamburg, HRB 86891

--

--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Mike Frysinger]

should we start a dev.c.o page for troubleshooting custom build enrollments ?

-mike

[Mattias Nissler]

In the long run, that might be useful. However, at this point I don't see a common pattern of roadblocks that people run into emerging from the mailing list posts we've seen thus far, so I'd rather gather a few more - unless you already have a good idea on what areas should be covered on the page.

[John W.]

Hi Guys,
I'm trying to load chromiumos on aspireone netbooks.  I have it loaded, but I just can't seem to get them enterprise enrolled.  I'm getting the Oops! "A network communication problem occurred during authentication.  Please check your netwrok connection and try again"
Are their step by step instruction on how to fix this posted anywhere?  I'm understanding this is some type of issue with SN?

On Friday, March 27, 2015 at 12:21:26 PM UTC-4, Ian Bloss wrote: