vadud,
I'm guessing a bug. I tried similar, but with a different AD user. Looks fine, before and after systemctl restart.
[root@spikerealmd02 sssd]# id spike_white
uid=25431(spike_white) gid=25431(spike_white) groups=25431(spike_white),1010(amerunixusers)
[root@spikerealmd02 sssd]# sss_override user-add spike_white -u 4311
SSSD needs to be restarted for the changes to take effect.
[root@spikerealmd02 sssd]# sss_override user-show spike_white
Spike_White@amer.dell.com::4311:::::
[root@spikerealmd02 sssd]# systemctl restart sssd
[root@spikerealmd02 sssd]# sss_override user-show spike_white
Spike_White@amer.dell.com::4311:::::
[root@spikerealmd02 sssd]# sss_override user-export foo
[root@spikerealmd02 sssd]# cat foo
Spike_White@amer.dell.com::4311:::::
[root@spikerealmd02 sssd]# sssd --version
1.16.0
[root@spikerealmd02 sssd]#
So -- good on version 1.16.0.
I'm curious where these sssd overrides reside. I know for 'user' and 'group' access additions, they ultimately end up in /etc/sssd/sssd.conf file. Not so for sss overrides.
Spike