Account - Can an account called "classroom" be created?

I see no reason the name "classroom" couldn't be used for a username. But I guess the logical test would be to use the GUI - System Preferences > Users & Groups - to try creating the account there. If it allows it, then likely the OS allows for it. If it's not working in your policy, I would check what password you are assigning to it. I know in the past the Jamf process of creating accounts sometimes ran into issues with passwords that used certain characters. If you're using a password with any complex characters in it, maybe try assigning it a simple password and see if that works.

If you create a new test policy that uses sysadminctl to create the user do you still encounter the problem? Maybe this is a bug in how the Jamf binary creates users vs a weird Apple restriction due to the new classroom features.

-UID -shell -hint -admin -home are additional options

sysadminctl -adminUser $existingAdmin -adminPassword $existingAdminPW -addUser $newUsername -fullName $fullName -password $newUserPassword

@mm2270, I was able to create accounts via System Preferences with no issues. @sshort, I didn't use the sysadminctl command because I'm not familiar with it but did use the old dscl command and was able to successfully create the account. I will have to get familiar with that command but in the meantime with the help of both of you, I'm isolating the issue down. This is just so odd that I can't create this account the official Jamf way through a policy. I may pull in Jamf support.

Cheers!

Do learn how to use sysadminctl, as it's really the Apple approved way of creating accounts, making changes to them, etc. dscl is a great tool, but is outdated and you may run into issues using it.
In case it helps, there is no manpage for sysadminctl, strangely. You can do sysadminctl -help though to get it's help page. That help page isn't the most, erm, helpful, but there are some blog posts out there that walk through some of the specific functions.

As for the issue, did you check the password issue like I mentioned? If so, and you still can't log into the account, then it's possible Jamf's existing method of creating new user accounts has finally run it's course. I'm not sure if it's still using older dscl commands, but it's possible. If so, they should update it to sysadminctl now.

@mm2270, I did use a very easy password when I did it the official way through Jamf. I even created a policy for another account and used the same password that I used for the classroom account and it was successful. I've concluded that it doesn't like classroom for an account name. Did you by chance try to create a policy for an account called classroom? If so, what was your result?

@joethedsa No, I didn't try it yet, but I'm going to do that now. Just so we're on the same page, the OS I'll be testing on will be 10.14.3 and using Jamf Pro 10.10.1. Not sure if that matches up with your testing environment, but that's what I have on hand to work with.

One last item, since it might be important (though it shouldn't matter), were you using standard or admin as the type of account the policy was creating?

I'll let you know the results.

@mm2270, I tried this on 10.13.4 and 10.14.3. I tried both a standard and an admin account. I've been doing it from an Out of Box OS too in case that matters. I am on Jamf Cloud 10.10.1.

@joethedsa Ok, so I ran my test - no issues. The policy ran, created an account called "classroom" for both the short name and the full name, as a local admin. This was using the built in "Local Accounts" payload. I was able to then login just fine to the account.

I'll run another test, maybe as a standard account this time, and let you know what I see. So far though, I'm not seeing a problem with it.

I didn't ask this before, but, would there be anything, like a Config Profile perhaps, that is blocking logging in to your Macs in anyway? It's possible to set up login restrictions, so for example, local accounts cannot log in but directory based ones can and so on. There wouldn't be any profiles assigned to the machine that's preventing those accounts from logging in is there?

Edit: Just thought of another question - since you are talking about "classroom" accounts, are these Macs enrolled via DEP and Apple School Manager? If so, I wonder if perhaps there is some restriction on ASM/DEP enrolled Macs that prevents them from using a "classroom" account. This goes back to your original thought up top. I suppose it's possible, though I haven't heard of that. I only use ABM + DEP though, so I don't know what differences there are with Apple School Manager.

@mm2270, Apologies for the delayed response. I do have a Configuration Profile for the same computer. I just confirmed that when I remove the config profile, the issue is not there. I don't see any indication in the profile that would prevent it except possibly using the name "Classroom Deployment Configuration" as the name. It may not like me using the word "Classroom" as part of the name. This has at least narrowed down where the issue is coming from. I'll continue to work on this. I'll check back in after some more tests have been done.

To answer your last question, I do use DEP and ASM so I'll have to keep that in mind too.

@mm2270, I've finally figured out what the issue is. In my Configuration Profile, in the Login Window (Payload) > Access > , I had "Local-only users may log in" unchecked. The reason for this is we are in an Active Directory environment. I thought that having that checked, it would prevent AD users from being able to log in (in my view this seems backwards). It still doesn't make sense that this account called "classroom" is the only account having this issue as mentioned in my earlier thread. Thanks for the mention of the Configuration Profile.