Is it considered secure to store a symmetric encryption key in a file on a networked Windows file server, accessed through a "share"? I would use the "Security" tab on the folder containing the key file to make sure only the needed service accounts have read access and the relevant support group has read/write access.
This totally depends on whether it meets your risk assessment for the task in which you are using it. It maybe totally fine or it maybe a very bad idea.
You need to know. What are the results of your risk assessment and what are your security policies?
No one on here can answer this without a more detailed question relating to the what you are are wanting to secure.
Just make sure if you do this that it meets all of your policy and legislation/compliance requirements you maybe following.
For most situations I wouldn't consider this a good idea, but as ISMSDEV said, it depends on your threat model and what you are protecting against.
But some of the risks you'd have to consider are:
SMB only supports encryption starting with v3, so you'd have to ensure that there was no way they key was accessed by older clients or if someone authorized accesses the key, an attacker could sniff it off the network.
There are also the risks associated with someone gaining direct access to the file server and getting access to the key.
But whether those risks are acceptable / manageable comes down to your threat model and what your defending against.
Edit: Corrected that SMB3 does do encryption
As other answers have said, it depends on your risk model. Let's explore what some risk models might look like, from weakest to strongest:
1. SMB is secure. Admins are trustworthy. Attackers have no physical access to the server.
If there is only a small amount of destruction or monetary loss that an attacker with the key could cause, then this is a perfectly acceptable risk model, and your solution is fine.
2. SMB has too many CVEs for my comfort
3. Admins are not trustworthy
Do Windows domain admins really need access to the key anyway?
4. Physical attacks on the server are possible
Attackers could yank the hard drive of the server, or do a cold boot attack by yanking the RAM sticks out of the running server. In this case, you're vulnerable as long as the key's plaintext exists on the file server's disk or memory. Full Disk Encryption like BitLocker helps with HDD-yanking, but not with RAM-yanking.
If 1. lines up with your threat model, then what you are doing is fine. But if your threat model includes any of 2. 3. or 4., then you probably want to do something like use public key encryption to protect the key file on the share, using tools like openssl or gpg, where each server / service account has its own private key.
Principle of least privilege
Rather than asking "is this good enough?", which is the mindset of starting with no security and adding it until you're comfortable, I would encourage you to change your thinking to:
Nobody has access except the people / accounts that actually need it.
This is a proactive defence-in-depth mindset.
If the admins placing the key on the file server are the only ones needing write access, then make sure they are the only ones with write access. If the service accounts are the only things needing read access, then make sure they are the only ones with read access. If there's no reason to have the key in plaintext on the file server, then don't. If the domain admins don't need to read/write the plaintext, then make sure they can't. And so on.
Obviously it very much depends on, what you are using the encryption key for. Be aware that this is not safe. Besides possible flaws in access configuration and windows share, you need to be aware that this key is stored plain text on the hard disk.
If this is a virtual machine, attackers could also get a copy of the VM image... and simply the key.
So obviously the group of humans, who have access to this key is much bigger than you might think.
I first wanted to provide the short answer no, but stackexchange asked me to type at least 30 characters ;-)