ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Microsoft Fail - SQL Server on Linux does not log successful logins

    Scheduled Pinned Locked Moved IT Discussion
    36 Posts 8 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • DustinB3403D
      DustinB3403 @dafyre
      last edited by DustinB3403

      @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

      If I always connect from 192.168.60.60 and suddenly, I'm connecting from 200.100.50.10, then that should be cause for some alarm.

      This goes to the point of, you'd track your SSH logins, not the SQL database logins.

      Edit for clarity: You'd track your SSH logins first, and then if you needed you'd monitor the database.

      1 Reply Last reply Reply Quote 0
      • DustinB3403D
        DustinB3403 @dafyre
        last edited by

        @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

        If I always connect from 192.168.60.60 and suddenly, I'm connecting from 200.100.50.10, then that should be cause for some alarm.

        As another point, this isn't at all impossible, public DHCP addresses change all of the time. So if a user was working from home or traveling they could get a different IP every 8 hours.

        scottalanmillerS dafyreD 2 Replies Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller @DustinB3403
          last edited by

          @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

          @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

          If I always connect from 192.168.60.60 and suddenly, I'm connecting from 200.100.50.10, then that should be cause for some alarm.

          As another point, this isn't at all impossible, public DHCP addresses change all of the time. So if a user was working from home or traveling they could get a different IP every 8 hours.

          In that one example, it would be from internal to external. That you might be able to track usefully.

          1 Reply Last reply Reply Quote 0
          • DustinB3403D
            DustinB3403
            last edited by

            Of course, in most cases you'd have an application which would connect to the database and never actually "login" in the ways we've discussed so far unless you needed to manually edit the database.

            1 Reply Last reply Reply Quote 0
            • dafyreD
              dafyre @DustinB3403
              last edited by

              @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

              I think Scott was asking why do you need a physical workstation connected to your SQL database.

              Um.... what else am I going to use? I gotta have something to use to run my SSH Client or SSMS.

              DustinB3403D 1 Reply Last reply Reply Quote 0
              • dafyreD
                dafyre @DustinB3403
                last edited by

                @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                You'd SSH into your SQL server as a server user, and if you had to from there login to the SQL database as the admin (or another SQL user).

                I don't argue that you could do this. However, tools like SSMS are great for syntax checking and providing other utility that, while could be done from a CLI session are more difficult.

                This is especially true when altering stored procedures or running complex queries.

                IRJI 1 Reply Last reply Reply Quote 0
                • DustinB3403D
                  DustinB3403 @dafyre
                  last edited by

                  @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                  @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                  I think Scott was asking why do you need a physical workstation connected to your SQL database.

                  Um.... what else am I going to use? I gotta have something to use to run my SSH Client or SSMS.

                  But it doesn't get attached directly to the database. It's external either over the LAN or WAN.

                  dafyreD 1 Reply Last reply Reply Quote 0
                  • dafyreD
                    dafyre @DustinB3403
                    last edited by

                    @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                    @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                    If I always connect from 192.168.60.60 and suddenly, I'm connecting from 200.100.50.10, then that should be cause for some alarm.

                    As another point, this isn't at all impossible, public DHCP addresses change all of the time. So if a user was working from home or traveling they could get a different IP every 8 hours.

                    My point was about connections from unexpected ip addresses / places.

                    Mobile users should be connected via VPN (or SSH Tunnel or ZT or Jump Box) or some other method that is known and expected.

                    1 Reply Last reply Reply Quote 0
                    • dafyreD
                      dafyre @DustinB3403
                      last edited by

                      @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                      @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                      @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                      I think Scott was asking why do you need a physical workstation connected to your SQL database.

                      Um.... what else am I going to use? I gotta have something to use to run my SSH Client or SSMS.

                      But it doesn't get attached directly to the database. It's external either over the LAN or WAN.

                      You are confusing me here. Are you talking about being directly attached to the physical server?

                      1 Reply Last reply Reply Quote 0
                      • IRJI
                        IRJ
                        last edited by

                        First of all you use a bastion host, so you have to SSH which is obvious. You still need to connect to the database. The bastion host only allows incoming connections from VPN.

                        SO you need,

                        1. VPN connection with MFA

                        2. Bastion Host Connection

                        3. Database Connection

                        You cant just use some random IP.

                        1 Reply Last reply Reply Quote 0
                        • IRJI
                          IRJ
                          last edited by

                          Using SSH and connecting to a DB are totally different. Not related at all. SSH is just used as tunnel.

                          1 Reply Last reply Reply Quote 0
                          • IRJI
                            IRJ @dafyre
                            last edited by

                            @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                            @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                            You'd SSH into your SQL server as a server user, and if you had to from there login to the SQL database as the admin (or another SQL user).

                            I don't argue that you could do this. However, tools like SSMS are great for syntax checking and providing other utility that, while could be done from a CLI session are more difficult.

                            This is especially true when altering stored procedures or running complex queries.

                            The cross platform CLI is still in beta. The Linux tool does alot, but not all the stuff you can do with SSMS or Azure Data Studio

                            JaredBuschJ 1 Reply Last reply Reply Quote 0
                            • JaredBuschJ
                              JaredBusch @IRJ
                              last edited by JaredBusch

                              @IRJ said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                              @dafyre said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                              @DustinB3403 said in Microsoft Fail - SQL Server on Linux does not log successful logins:

                              You'd SSH into your SQL server as a server user, and if you had to from there login to the SQL database as the admin (or another SQL user).

                              I don't argue that you could do this. However, tools like SSMS are great for syntax checking and providing other utility that, while could be done from a CLI session are more difficult.

                              This is especially true when altering stored procedures or running complex queries.

                              The cross platform CLI is still in beta. The Linux tool does alot, but not all the stuff you can do with SSMS or Azure Data Studio

                              Windows: SSMS does everything in GUI.
                              Windows/Linux/Mac: Azure Data Studio does everything via SQL, some limited bits via gui, but mostly just to create the SQL for you.

                              CLI is just raw SQL.

                              @DustinB3403 has no idea WTF he is talking about.

                              1 Reply Last reply Reply Quote 0
                              • 1
                              • 2
                              • 2 / 2
                              • First post
                                Last post