Closed trondhindenes closed 1 year ago
Which release are you seeing this issue with and what environment are you executing it under?
Thanks
Chris
On 23 Dec 2022, at 09:04, Trond Hindenes @.***> wrote:
Describe the bug ssosync crashes in some situations
To Reproduce I'm not sure how easy this would be to reproduce, but sso sync is crashing in some situations:
INFO[0002] get existing aws users
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xaf157f]
goroutine 1 [running]: github.com/awslabs/ssosync/internal.ConvertSdkUserObjToNative(0xc00032c240)
The only thing I can think if that I have a manually provisioned user in my identity store that has the same name/email as a user in the google directory. Could that be it? Better logging would make it way easier to figure out what's happening, I have set it to "trace" but it still doesn't show any detailed info about what it's trying to do.
— Reply to this email directly, view it on GitHub https://github.com/awslabs/ssosync/issues/114 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVULYMU72PUP7SS6VH54FTWOVTJRANCNFSM6AAAAAATHRFPXA . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ABVULYKOISRJQOI6XNVT4UTWOVTJRA5CNFSM6AAAAAATHRFPXCWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFT4WMW4.gif Message ID: @.***>
Hi, I cloned the repo and built it. I think the error was that an existing manually provisioned user existed, that collided with a user sso-sync attempted to provision.
Hello,
I have exactly the same problem when I use the "groups" synchronization method
It doesn't matter if the user/group is present or not on AWS
Project version: 2.0.0 Go version : 1.19.4 Environment: Local
Line I use :
./ssosync -d\
-u adminworkspace@google.com\
-r aws-region\
-i d-xxxxxxxxxxx\
-g 'name:aws*'\
-e $SSOSYNC_SCIM_ENDPOINT -t $SSOSYNC_SCIM_ACCESS_TOKEN
Ran into same issue. This happens e.g. with the SSO user configured by Control Tower. For some reason it does not have email type and primary set, so this code fails: https://github.com/awslabs/ssosync/blob/master/internal/sync.go#L860
Fixed doing this:
--- a/internal/sync.go
+++ b/internal/sync.go
@@ -855,6 +855,9 @@ func ConvertSdkUserObjToNative(user *identitystore.User) *aws.User {
userEmails := make([]aws.UserEmail, 0)
for _, email := range user.Emails {
+ if email.Type == nil || email.Value == nil || email.Primary == nil {
+ continue
+ }
userEmails = append(userEmails, aws.UserEmail{
Value: *email.Value,
Type: *email.Type,
This will however end up deleting that user.
Thank you for extra context.
There are other control tower related nuances, so I’ll take a look at how we handle this.
Kind regards,
Chris
On 11 Jan 2023, at 10:31, Pelle Johnsen @.***> wrote:
Ran into same issue. This happens e.g. with the SSO user configured by Control Tower. For some reason it does not have email type and primary set, so this code fails: https://github.com/awslabs/ssosync/blob/master/internal/sync.go#L860 https://github.com/awslabs/ssosync/blob/master/internal/sync.go#L860
Fixed doing this:
--- a/internal/sync.go +++ b/internal/sync.go @@ -855,6 +855,9 @@ func ConvertSdkUserObjToNative(user identitystore.User) aws.User { userEmails := make([]aws.UserEmail, 0)
for _, email := range user.Emails {
This will however end up deleting that user.
— Reply to this email directly, view it on GitHub https://github.com/awslabs/ssosync/issues/114#issuecomment-1378540533 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVULYP7IZ7NY4IQTWMWJUDWR2DWRANCNFSM6AAAAAATHRFPXA . You are receiving this because you commented. https://github.com/notifications/beacon/ABVULYPEMROCWNPNH6ELKVTWR2DWRA5CNFSM6AAAAAATHRFPXCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSFLN7K.gif Message ID: @.***>
Resolved by release v2.0.2
Describe the bug ssosync crashes in some situations
To Reproduce I'm not sure how easy this would be to reproduce, but sso sync is crashing in some situations:
The only thing I can think if that I have a manually provisioned user in my identity store that has the same name/email as a user in the google directory. Could that be it? Better logging would make it way easier to figure out what's happening, I have set it to "trace" but it still doesn't show any detailed info about what it's trying to do.