Bash – dialout group missing

You could use the lid command to get a list of users in aa, and the loop over that list to add them to tomcatdeploy:

for u in $(lid -g -n aa); do usermod -a -G tomcatdeploy $u; done

newgrp only gives you access to a group that you already have access to. Sounds useless? Basically, yes. It's mostly a leftover from the days when a process couldn't be a member of multiple groups. You can also gain access to a group that's protected by a password, but that's extremely uncommonly used.

From the kernel's point of view, each process is in one or more groups. setgid can only be used when running as root or in setgid programs (to swap between the real (run-by) and effective (run-as) groups). The kernel doesn't know about user and group databases.

User and group databases (/etc/passwd, /etc/group, /etc/security/group.conf, LDAP, …) are managed by login, su and other programs that manage logins and privilege elevation, often through PAM. When you log in, you get assigned to the groups listed in /etc/passwd, /etc/group, and other files through pam_groups; the process looks like this:

gid_t groups[…] = /*extra GIDs computed from /etc/group and so on*/;
setgroups(sizeof(groups)/sizeof(gid_t), groups);
setgid(gid); /*main GID read from /etc/passwd*/
setuid(uid);
execve(shell, "-sh"); /*shell read from /etc/passwd*/

In words: renouncing root privileges (i.e. changing to the target user) is done after all other privilege management, just before invoking the user's shell. After the process is no longer running as root, it can't gain any extra groups.

If you've just added a user to a group, this will take effect the next time the user logs in. If you start another session by logging in in another terminal or over ssh, the processes in that session will have whatever groups your user was in at the time you logged in. You can use the groups or id command to see what groups you (meaning the particular process you launched groups from) are a member of.

So, I've answered your explicit questions (newgrp is doing its job, which isn't what you thought). I may or may not have solved your problem. It's unusual for applications that don't log you in to look up user and group databases; normally access permissions would be decided by checking whether the requesting process is a member of the relevant group. If you have a problem with a particular application, tell us which.